#911572 coreutils: incorrect and inconsistent quoting in ls output

Package:
coreutils
Source:
coreutils
Description:
GNU core utilities
Submitter:
Vincent Lefevre
Date:
2025-04-21 01:42:02 UTC
Severity:
normal
Tags:
#911572#5
Date:
2018-10-22 01:13:13 UTC
From:
To:
I get the following with ls (GNU coreutils) 8.30.

zira% touch a=b a=b\&c
zira% ls a=b*
'a=b'  'a=b&c'
zira% ls -b a=b*
a=b  a=b&c
zira% ls -F a=b*
'a=b'  'a=b&c'
zira% ls -bF a=b*
a\=b  a\=b&c

AFAIK, the = character is not a shell metacharacter (except with zsh
but only in the first position), thus does not need to be quoted.

Moreover, while & is not a metacharacter, it is a special character
that should be quoted for practical reasons.

In particular, this inconsistency with -bF makes a\=b&c unusable by
copy-paste, as a\=b&c can't be used directly in a shell command, and
'a\=b&c' is not OK either.

Note: Such filenames with = and & can be produced by "wget -r".
#911572#10
Date:
2018-10-22 11:43:24 UTC
From:
To:
The reason \= is quoted with -bF is to distinguish socket
names that end in =. An edge case indeed, though the issue
is not particular to '=', but all of the classifier chars.
#911572#15
Date:
2018-10-22 11:43:24 UTC
From:
To:
The reason \= is quoted with -bF is to distinguish socket
names that end in =. An edge case indeed, though the issue
is not particular to '=', but all of the classifier chars.
#911572#20
Date:
2018-10-22 14:48:24 UTC
From:
To:
That's undocumented, and IMHO, unnecessary in practice (such
appended characters can only occur at the end, and even in this
case, colors remove any ambiguity for me).

It wouldn't be much an issue if a classifier char would be quoted
only when it is at the end, because:
  * such a char at the end of a filename is very rare;
  * completion can handle it easily (while when it occurs earlier,
    it can be in a common prefix, e.g. for filenames obtained with
    "wget -r").

Well, I've used -b by default for more than 20 years, mainly due to
non-graphic characters (the goal was not to do copy-paste of such
filenames, but for security reasons). I see that --quoting-style
is rather new, but its documentation is still very inaccurate, and
--quoting-style=shell-escape is more ugly than -b. For instance,
with -b, one gets

  a\ab

(not copy-pastable, but it won't be generated by common programs,
so that's not an issue), while --quoting-style=shell-escape gives

  'a'$'\a''b'

which is rather unreadable.
#911572#25
Date:
2025-04-20 17:12:31 UTC
From:
To:
#911572#30
Date:
2025-04-20 21:51:17 UTC
From:
To:
This bug is still not fixed.

Note that the reason given for the quoting of "=" was:

  The reason \= is quoted with -bF is to distinguish socket names
  that end in =.

in <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911572#10>.

But
  * This is not what is documented in the manual ("Quote nongraphic
    characters in file names using alphabetic and octal backslash
    sequences like those used in C.") and in the man page.
  * The "*" character, which is used for executables (* at the end),
    is not quoted. So, even if there were a reason to quote characters
    added by "-F", this is not the case.