broken ls in coreutils 8.25

[Harald Dunkel]

Hi folks,

how comes that suddenly I have to define an environment variable

QUOTING_STYLE=literal

for something that worked very well since the 70s? I appreciate
your continuous effort to improve coreutils, but this change is a
bad move.


Harri

[Pádraig Brady]

Post by Harald Dunkel
Hi folks,
how comes that suddenly I have to define an environment variable
QUOTING_STYLE=literal
for something that worked very well since the 70s? I appreciate
your continuous effort to improve coreutils, but this change is a
bad move.

The reasons we changed the default was:

- It only happens when outputting to terminals
- It disambiguates the output for users
- Output can be pasted back in the shell for further processing
- Users can get back to the old format by adding -N to their ls alias

I see some disadvantages as:

- Slightly misaligns -l output when some files have spaces
- Produces longer output for file names with single quotes

So that's 2 functional advantages over 2 aesthetic disadvantages.
Given the advantages especially for new users and the complications of
producing shell quoted file names oneself, we chose the new default.

thanks,
Pádraig

[Harald Dunkel]

Hi Pádraig,

Post by Pádraig Brady
- It only happens when outputting to terminals

This means if you use "ls -1 | somescript" the script will
not see the quoting style. Don't you think that this is
inconsistent, not to mention that a script would benefit
much more from this quoting style than a human?

Post by Pádraig Brady
- It disambiguates the output for users

This means that the user has to count '\' and "'" in the output
of ls to get the "real" filename.

Post by Pádraig Brady
- Output can be pasted back in the shell for further processing

This means that it useful only on a graphic terminal, for people
using a mouse, but it affects all users using "ls"

Post by Pádraig Brady
- Users can get back to the old format by adding -N to their ls alias

Or they can use busybox, Solaris, AIX, HP-UX and tons of others.

Post by Pádraig Brady
- Slightly misaligns -l output when some files have spaces

I cannot express *how* annoying this is, e.g. if you are using
"ls -al" looking for a file or directory. The output appears to
be completely messed up, since the "." and "'" at the beginning
of a file name are very hard to distinguish, esp. in a long
listing. It appears to be unsorted. Artificial sample:

% export LANG=en_US.UTF-8
% ls -al
total 164
drwxrwxrwt 13 root root 4096 Feb 2 06:55 .
drwxr-xr-x 43 root root 4096 Jan 14 12:34 ..
- -rw-r--r-- 1 harri harri 0 Feb 2 06:55 a
- -rw-r--r-- 1 harri harri 0 Feb 2 06:55 .a
- -rw-r--r-- 1 harri harri 0 Feb 2 06:55 '.a b'
- -rw-r--r-- 1 harri harri 0 Feb 2 06:55 .a.b
- -rw-r--r-- 1 harri harri 0 Feb 2 06:55 '.a'\''b'
- -rw-r--r-- 1 harri harri 0 Feb 2 06:55 'a b'
- -rw-r--r-- 1 harri harri 0 Feb 2 06:55 a.b
- -rw-r--r-- 1 harri harri 0 Feb 2 06:55 'a'\''b'

Post by Pádraig Brady
- Produces longer output for file names with single quotes

This means that some file names appear to have a different length,
but they don't.

Post by Pádraig Brady
So that's 2 functional advantages over 2 aesthetic disadvantages. Given the advantages especially for new users and the complications of producing shell quoted file names oneself, we chose the new default.

Sorry, but I don't see the functional advantage, since the
new quoting style is not used if you are using a pipe.
You get it only on terminal, writing directly to the user.

The "aesthetic disadvantage" exists and is underestimated here,
since the main purpose of ls is to produce readable output. Now
the user needs some integrated quoting filter to translate the
shown directory elements back to their real names. I doubt that
new users will benefit from this.

Don't get me wrong, I have no problem with the new quoting style.
I don't see the advantage of making it the default.


Regards
Harri

[Eric Blake]

Hi Pádraig,

Post by Pádraig Brady
- It only happens when outputting to terminals

This means if you use "ls -1 | somescript" the script will
not see the quoting style. Don't you think that this is
inconsistent, not to mention that a script would benefit
much more from this quoting style than a human?

No. ls _already_ behaves differently when not outputting to a terminal
(that is, 'ls | somescript' and 'ls -1 | somescript' behave the same,
because a non-terminal implies -1).

Post by Pádraig Brady
- It disambiguates the output for users

This means that the user has to count '\' and "'" in the output
of ls to get the "real" filename.

Yeah, but which are you more likely to do, retype the "real" filename
manually (and insert your own shell quoting as appropriate), or
copy-and-paste the existing output with a mouse click or two?

Post by Pádraig Brady
- Output can be pasted back in the shell for further processing

This means that it useful only on a graphic terminal, for people
using a mouse, but it affects all users using "ls"

These days, how many users are NOT using a graphical terminal? Again,
it only affects output to a terminal, and it is very easy to adjust your
login setups to change the defaults to something you like, so that
_your_ terminal behaves the way you want.

[Tomas Nordin]

Post by Eric Blake

Post by Harald Dunkel
Hi Pádraig,

Post by Pádraig Brady
- It only happens when outputting to terminals

This means if you use "ls -1 | somescript" the script will
not see the quoting style. Don't you think that this is
inconsistent, not to mention that a script would benefit
much more from this quoting style than a human?

No. ls _already_ behaves differently when not outputting to a terminal
(that is, 'ls | somescript' and 'ls -1 | somescript' behave the same,
because a non-terminal implies -1).

Post by Harald Dunkel

Post by Pádraig Brady
- It disambiguates the output for users

This means that the user has to count '\' and "'" in the output
of ls to get the "real" filename.

Yeah, but which are you more likely to do, retype the "real" filename
manually (and insert your own shell quoting as appropriate), or
copy-and-paste the existing output with a mouse click or two?

When I type `"` or `'` followed by some letter(s) and do tab completion,
I get the rest of the "real" filename and close quote for free. I am
more likely to do that.

Post by Eric Blake

Post by Harald Dunkel

Post by Pádraig Brady
- Output can be pasted back in the shell for further processing

This means that it useful only on a graphic terminal, for people
using a mouse, but it affects all users using "ls"

These days, how many users are NOT using a graphical terminal? Again,
it only affects output to a terminal, and it is very easy to adjust your
login setups to change the defaults to something you like, so that
_your_ terminal behaves the way you want.

[Harald Dunkel]

This means that the user has to count '\' and "'" in the output of ls to get the "real" filename.

Yeah, but which are you more likely to do, retype the "real" filename manually (and insert your own shell quoting as appropriate), or copy-and-paste the existing output with a mouse click or two?

Talking about copy and paste: Have you tried to copy and paste
a string like

'mom'\''s pictures.png'
or
mom'\''s pictures.png

into the file selection box of your favorite gui application?
How likely is that this gui knows how to handle the "'" and
the "\'" correctly?

How are you going to explain a noob that he has to edit the
pasted string to

mom's pictures.png

to make it work?

Post by Pádraig Brady
- Output can be pasted back in the shell for further processing

This means that it useful only on a graphic terminal, for people using a mouse, but it affects all users using "ls"

These days, how many users are NOT using a graphical terminal? Again, it only affects output to a terminal, and it is very easy to adjust your login setups to change the defaults to something you like, so that _your_ terminal behaves the way you want.

Understood. My point is that the new default has some advantages
for a few (e.g. copy and paste from one shell to another, if you
manage to hit the "'" on copy), but a lot of disadvantages for many
(unreadable and apparently unsorted screen output, user is forced
to "unquote" the text in his mind, breaks copy and paste to other
applications, poor usability on the "copy" part).


Regards
Harri

[Pádraig Brady]

Post by Harald Dunkel

This means that the user has to count '\' and "'" in the output of ls to get the "real" filename.

Yeah, but which are you more likely to do, retype the "real" filename manually (and insert your own shell quoting as appropriate), or copy-and-paste the existing output with a mouse click or two?

Talking about copy and paste: Have you tried to copy and paste
a string like
'mom'\''s pictures.png'
or
mom'\''s pictures.png
into the file selection box of your favorite gui application?
How likely is that this gui knows how to handle the "'" and
the "\'" correctly?
How are you going to explain a noob that he has to edit the
pasted string to
mom's pictures.png
to make it work?

Yes this is a functional disadvantage worth mentioning,
though I'm still not convinced it will impact many.
Personally I rarely if ever paste from shell to gui since
one doesn't normally have the gui app in the right dir,
and if you do it's usually easier to select the file
from the file dialog you'd be opening anyway.

Generally how I would interact with a gui app from shell is:

xdg-open .
xdg-open 'pasted name'
gui-app 'pasted name'
realpath 'pasted name' # Paste output of this to gui app (gives dir)

Again if your edge case usage doesn't fit the above,
then you can just add -N to your ls alias
(noting that will fail in this use case also for
chars that are then represented with ?)

cheers,
Pádraig.

[Mike Frysinger]

Post by Harald Dunkel

Post by Pádraig Brady
- Output can be pasted back in the shell for further processing

This means that it useful only on a graphic terminal, for people
using a mouse, but it affects all users using "ls"

that's incorrect. screen/tmux/emacs and i'm sure more all have methods
for selecting/copying/pasting chunks of text using only the keyboard.

Post by Harald Dunkel

Post by Pádraig Brady
- Users can get back to the old format by adding -N to their ls alias

Or they can use busybox, Solaris, AIX, HP-UX and tons of others.

then export the env var instead. this is not that big of a deal.
-mike

[Tomas Nordin]

Post by Pádraig Brady

Post by Harald Dunkel
Hi folks,
how comes that suddenly I have to define an environment variable
QUOTING_STYLE=literal
for something that worked very well since the 70s? I appreciate
your continuous effort to improve coreutils, but this change is a
bad move.

- It only happens when outputting to terminals
- It disambiguates the output for users
- Output can be pasted back in the shell for further processing
- Users can get back to the old format by adding -N to their ls alias

Or could it be that users who like to copy/paste file names in a
terminal can be guided to add something like --quoting-style=shell to
their ls alias. No? I never read or heard of this being a problem.

Post by Pádraig Brady
- Slightly misaligns -l output when some files have spaces
- Produces longer output for file names with single quotes
So that's 2 functional advantages over 2 aesthetic disadvantages.
Given the advantages especially for new users and the complications of
producing shell quoted file names oneself, we chose the new default.
thanks,
Pádraig