[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ls output changes considered unacceptable

From: Michael Stone
Subject: Re: ls output changes considered unacceptable
Date: Wed, 17 Feb 2016 20:46:41 -0500
User-agent: Mutt/1.5.23 (2014-03-12)

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'  

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]