bug#24926: ls output has been made ugly

[Eric Blake]

On 11/11/2016 03:25 PM, L. A. Walsh wrote:
> Eric Blake wrote:
>>
>> If the idea is that the quoting is there to make copy-and-pasting into a
>> shell command line easier, then there is nothing we can do that is less
>> aggressive, since failing to quote spaces changes what the shell will
>> do. 
> ----
>    I assume you are talking about "quoting-style=shell-always"
> and not the conditional quoting you get for "quoting-style=shell"?

quoting-style=shell-always uses quotes ALWAYS, even if the quotes are
redundant.  quoting-style=shell uses quotes ONLY if the shell could
otherwise interpret it differently without the quotes.  Reusing Paul's
example:

$ \ls --quoting-style=shell
'a  b'  c
$ \ls --quoting-style=shell-always
'a  b'  'c'

Note that 'a  b' needed quoting under both styles, but 'c' was conditional.

>>  If the idea is that the quoting should only be added to avoid
>> ambiguous situations, then maybe you are right that we can add further
>> heuristics to the quoting algorithm to disable quotes on output that is
>> unambiguous, even if it can't be pasted back into the shell.  Having two
>> different quoting modes, where you can choose between the options, may
>> be the way to go - but then you STILL have the problem of what to pick
>> as the default of those two modes when neither one was explicitly
>> requested.
>>   
> ----
>    Seems like the default is to not put quotes.  That's what
> is used now.  Why would you break it?

Paul was suggesting _yet another mode_ (which someone would have to
write patches for), which avoids quotes in all situations where the
output is unambiguous (a file 'a b' is unambiguous in 'ls' output even
without quotes, since the ambiguity only arises if you have two spaces;
but a file 'a  b' would still need quotes, as would a file that itself
contains literal quotes in the name), but also pointing out that the
definition of "not ambiguous" may be context sensitive (the ambiguity of
plain 'ls' [two spaces, embedded newline, or something that uses the
same mechanism we use for escaping the other ambiguous cases] differs
from the ambiguity of 'ls -l' [embedded newline, or something that uses
the same mechanism we use for escaping the other ambiguous cases],
because two spaces is ambiguous in one but not the other).

Personally, I think that trying hard to avoid quotes makes the addition
of quotes that much more surprising when hitting the corner cases, which
by their nature are already corner cases and therefore somewhat rare, so
I'd rather stick with a style that is very easy to describe ("if the
shell could misintepret it without quotes, add quotes; and this applies
regardless of the app using this quoting rule") over one that is
difficult ("if it matches potential ambiguity A, B, or C, add quotes -
but now you have to learn a different list of A, B, and C for every app
and context that has different ambiguities").

Furthermore, I _like_ quoting-style=shell (and NOT
quoting-style=shell-always) in one regards: when dealing solely with
file names that are declared portable according to POSIX,
quoting-style=shell is indistinguishable from quoting-style=literal.  It
is only on file names that are already inherently non-portable to all
possible file systems where the additional quotes calls my attention to
the potential portability issue, whereas quoting-style=always does not
have that benefit.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature