On Tue, Jan 2, 2018 at 3:26 PM, Ben Hutchings <b...@decadent.org.uk> wrote:
> The output of ls on a terminal has never, in general, been an accurate
> reflection of the contents of a directory. Consider that filenames can
> contain *any* byte value other than '\0' or '/', so including carriage
> return, newline, backspace and escape characters.
Yes, but those are not characters one would reasonably expect to encounter in
a filename or at least would only run into them when expecting to find them
there, whereas one may often run `ls` to see if they correctly escaped the
output of a command (for instance). Both `(` and `'` are commonly found in
document names, too.
> ls also uses multiple columns by default, but without quoting you can't
> generally tell where the columns are, e.g. is:
>
> aa ba ca ab bb cb
>
> a list of 6 two-letter filenames, or 2 filenames with spaces in, or
> something else again?
This is a carefully chosen example where all entries have the same length; in
a more realistic context, column spacing can easily be determined in the
presence of entries of varying widths. Note that I specifically pointed out
the broken behavior of `ls -l`, including the revered `ls -ahltr`
> I think that the behaviour of single-quoting is very consistent across
> shells, in part because it is specified by POSIX.
You are correct; I should have used double quotes in my example. We're all
C/C++ programmers here, single quotes are for individual characters only ;-)
> Be careful what you wish for. But I think this will revert the recent
> change:
>
> alias ls='ls --literal'
Thanks for sharing that option, and I shall certainly make heavy use of it.
My final example which demonstrates precisely why this behavior only makes
things worse for both beginners and newcomers to the terminal alike remains
unaddressed:
```
mqudsi@buster ~> touch \'\test\(\'
mqudsi@buster ~> ls -l
-rw-r--r-- 1 mqudsi mqudsi 0 Jan 2 14:22 ''\''test('\'''
```
And with regards to the following from your later message:
> You're looking for the ls --quoting-style=WORD option of ls. ls defaults
> to shell-escape if the output is a terminal, and literal otherwise.
If I may be so bold as to disagree, the outut of `ls` executed in a terminal
without and not piped to any other process, is primarily meant for human
consumption. How often does "human consumption" manifest as copy-and-paste vs
"show me the contents of this directory so I can see what it contains?"
Modern shells have solved the escaping problem by using bracketed paste mode to
trigger escaping of content pasted to the terminal. For everyone else that
doesn't need to copy-and-paste and knows offhand that typing certain
characters in a shell requires them to be escaped, that quoting behavior is
only a source of confusion. If you don't have a mouse to copy-and-paste with
(and you're not using vim/tmux or some other esoteric method of selecting text
to copy and paste to the keyboard that would take more time than actually
typing out what you see on the screen), how does this change in any way make
things better or easier?
I really do appreciate that time and effort has gone into the implementation
of this feature, and that dismissing it out of hand like this is bound to
induce a defensive reply, but I ask you to consider that I ran into this bug
within the hour of deploying debian-testing, and in almost two decades of
using everything ranging from the most popular to the most esoteric unix-like
platforms out there, I have never had reason to spend so long or put this much
effort into understanding the output of `ls` or figuring out what files I
actually had on my filesystem. I am sure that I'm not going to be the only one
that is this flummoxed when buster is released with this breaking change - and,
seriously, if the filenames output by `ls` are not held sacrosanct, what is?
Mahmoud Al-Qudsi
NeoSmart Technologies
