[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ls output changes considered unacceptable
Re: ls output changes considered unacceptable
Wed, 17 Feb 2016 20:46:41 -0500
I backed out the default ls quoting style change for now in Debian.
I admit I simply missed the original RFC, and I apologize for that. I've
been hesitant to wade into this because the tone of much of the
criticism is frankly unpleasant, but I don't want to change a downstream
default without some explanation. Here are my thoughts:
It's not possible to make an older version of ls output in this style.
There are two problems in that. First, I'd prefer a change this dramatic
to be something that could be configured consistently across an
environment with differing releases. Second, I think that something this
dramatic should be evaluated in the wild for a bit before becoming the
It's not an interoperable solution. It happens to work for some narrow
use cases in some shells, but won't work for other use cases (e.g.,
copying from commandline to gui file dialog) or shells
(csh, dash, posh, yash). Some of those shells are defaults on some OSs,
or worse, they could lead to dramatically different results between
syntax tested interactively and syntax used in a shell script. On no
shell that I tested can you copy part of a quoted filename and tab
complete it. Support for tab completing through a quoted directory was
extremely inconsistent even in shells that recognize the basic syntax.
Ironically, the original solution (the ?'s) was more interoperable for
many use cases.
It's ambiguous. It isn't possible to tell from the output whether you're
looking at a really weird filename or something that's been escaped.
Recall the earlier point about the inability to configure a heterogenous
environment consistently, and the lack of visual indication of the
It's inconsistent. Some filenames are surrounded by quotes and some
aren't. I don't think that satisfies the "least surprise" principle.
(This is also true for some of the specifics raised in the point about
interoperability; things will "just work" sometimes and completely fail
at other times in ways which are not necessarily obvious.)
It's ugly and overly verbose. This one is completely subjective, but
there seems to be some strong sentiment around it. As a practical
matter, it doesn't matter much to me at all because I'm an
old school unix guy and my filenames are lower case ascii with no
spaces, except for the occasional Makefile or README. But I've seen what
happens when you run ls with this quoting style on a bunch of filenames
from a GUI system full of spaces and single quotes--the results are not
'I don'\''t think this is optimal.docx' 'My eye'\''s bleedin'\''.docx'
In contrast, the case for the change doesn't seem that compelling:
"It's less ambiguous" -- Maybe in some ways, but are there real-world
cases where it's a useful distinction? This was never a real barrier for
experienced users, who could just ls | xxd or somesuch, and in practical
terms inexperienced users are going to just use a gui to delete that
wacky file anyway.
"It's possible to copy and paste filenames with unprintable characters
at the command line" -- do people really do this on a routine basis?
What is the relative size of that set compared to the set who will find
it necessary to change the default back?
"Many of the criticisms are irrelevant for experienced users/admins" --
experienced users/admins weren't stymied by the original output/need to
set a quoting style, either. The change is most beneficial to
inexperienced users with certain use cases, which means it's valid to
question whether inexperienced users are more likely to run into cases
where the new output eases confusion or causes confusion.
"If people don't like it, they can turn it off" -- well, yeah, but they
can also just turn it on if they do like it, right?
For myself, I consider ls to primarily be a visualization tool, so
having output which maximizes human readability is a sine qua non. If
reducing the ambiguity of the output is really a goal, then the quoting
should be pervasive/consistent rather than changing on a per-file basis.
It should also be minimally verbose. I'd rather see the default be
--quoting-style=c than --quoting-style=shell-escape. I'm likely to set
the quoting style to literal for my own account regardless of the
default, because I'd rather save a few characters per filename when
looking at files on an SMB share and I've never hit a case where the ?
Where to go with this? I feel pretty strongly that changing the default
is a bad idea right now. Maybe with some broader & longer term
experience we'd have a better idea of whether it's truly useful, which
we can't have with something that's brand new. That said, I feel pretty
strongly that Debian's coreutils package shouldn't needlessly diverge
from upstream because I think consistency across distributions is
valuable in itself. I'm kicking the can down the road for now, but in
the long term I'd rather not carry a patch just to change an upstream
default. I hope maintainers from some of the other distributions are
following this, and that we can get a wider discussion; I suspect I'm
not the only one who dropped the ball on the RFC. I'd be especially
interested in seeing use cases from people who have found the new syntax
to be a workflow improvement, and the specifics thereof.