Re: ls output changes considered unacceptable

[Michael Stone]

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 
default.

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 
current QUOTING_STYLE.

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 
pretty:
'I don'\''t think this is optimal.docx'  'My eye'\''s bleedin'\''.docx'  
Simple.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 ? 
was insufficient.

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. 

Mike Stone