Re: ls is broken, what's next cd?

[Kamil Dudka]

On Tuesday, February 6, 2018 4:02:19 PM CET Kamil Dudka wrote:
> On Tuesday, February 6, 2018 3:31:11 PM CET Eric Blake wrote:
> > The change has already been made.  Even if we now revert it, users still
> > have to deal with versions in the wild that have the change.
> 
> If you revert it now, the change will not be observable by users of Red Hat
> Enterprise Linux as well as many other distributions with long term support.
> 
> Kamil

I discovered that Automotive Grade Linux reverts the upstream change in their
distribution of coreutils:


https://download.automotivelinux.org/AGL/release/koi/11.0.0/qemux86-64/deploy/sources/x86_64-agl-linux/coreutils-8.31-r0/disable-ls-output-quoting.patch

Just so you know.

Kamil

Re: ls is broken, what's next cd?

[Garreau, Alexandre]

please keep the current default, I like it

Re: ls is broken, what's next cd?

[Pádraig Brady]

On 16/02/18 02:49, Harald Dunkel wrote:
> Hi Ben,
> 
> On 02/15/18 08:16, Bernhard Voelker wrote:
>>
>> I'm not sure what's happening there, but it seems that your terminal
>> doesn't know how to display the 2-byte representation "c3 a4"; neither
>> gnome-terminal nor xterm have problems to display it here:
>>
>>$ /bin/ls -log /tmp/Q*
>>-rw-r--r-- 1 0 Feb 15 07:59 '/tmp/Qualitätssicherung final'
>>
> 
> I am using xterm. The /tmp file system uses iso8859-? in this case.
> The env says
> 
>   LANG=C
>   LC_ALL=C
> 
> Doesn't this mean, that German Umlaute should be escaped, since
> they are outside of scope of the C locale? Regardless whether
> the file system uses iso8859 or UTF8?

Yes that's one of the advantages of the new quoting.
In the presence of mixed encodings (between ls, file system, terminal),
one can always get a safe and usable file name by setting the C locale:

$ ls
Qualitätssicherung

$ LC_ALL=C ls
'Qualit'$'\303\244''tssicherung'

Re: ls is broken, what's next cd?

[Harald Dunkel]

Hi Ben,

On 02/15/18 08:16, Bernhard Voelker wrote:


I'm not sure what's happening there, but it seems that your terminal
doesn't know how to display the 2-byte representation "c3 a4"; neither
gnome-terminal nor xterm have problems to display it here:

   $ /bin/ls -log /tmp/Q*
   -rw-r--r-- 1 0 Feb 15 07:59 '/tmp/Qualitätssicherung final'



I am using xterm. The /tmp file system uses iso8859-? in this case.
The env says

LANG=C
LC_ALL=C

Doesn't this mean, that German Umlaute should be escaped, since
they are outside of scope of the C locale? Regardless whether
the file system uses iso8859 or UTF8?


Regards
Harri

Re: ls is broken, what's next cd?

[Bernhard Voelker]

On 02/13/2018 08:35 AM, Harald Dunkel wrote:

If I got this correctly, then the folks to benefit from this change
are GUI users, using copy-and-paste. Is this an argument to affect
the command line users?


Well, unless one is working on a bare tty without X or via network,
I would guess that there is a terminal application like xterm,
gnome-terminal, a kde terminal, etc., involved in 99% of the cases.
Thus, there /is/ the possibility to use for copy/paste.

Furthermore, the quoting gives you immediate visual feedback that
there's something unusual in the corresponding file name.


BTW, apparently the shell quoting-style in coreutils 8.26 (Stretch)


8.26 is quite old, and there have been further tweaks to the quoting
feature meanwhile (we're at 8.29).


misses to properly quote iso8859 chars, e.g. German Umlaute. Sample:

% ls --quoting-style=shell -al /tmp/Qual*
-rw-r--r-- 1 root root 0 Feb 13 08:27 '/tmp/Qualit?tssicherung final'


I'm not sure what's happening there, but it seems that your terminal
doesn't know how to display the 2-byte representation "c3 a4"; neither
gnome-terminal nor xterm have problems to display it here:

  $ /bin/ls -log /tmp/Q*
  -rw-r--r-- 1 0 Feb 15 07:59 '/tmp/Qualitätssicherung final'

  $ /bin/ls /tmp/Q* | od -tx1z
  000 2f 74 6d 70 2f 51 75 61 6c 69 74 c3 a4 74 73 73  >/tmp/Qualit..tss<
  020 69 63 68 65 72 75 6e 67 20 66 69 6e 61 6c 0a >icherung final.<
  037

Have a nice day,
Berny

Re: ls is broken, what's next cd?

[Harald Dunkel]

Hi Berny,

On 02/08/18 00:34, Bernhard Voelker wrote:

On 02/07/2018 10:12 AM, Harald Dunkel wrote:

I wonder who is supposed to benefit from this change? For a
human eye these constructs are simply unrecognizable, unless
you look*very*  closely.



:
:


This is nice IMO.
Your example was quite extreme, and therefore it's clear that
the listing would be hard to read in any style of ls output;
but: the new one can at least be used for copy/paste  ... without
any ambiguity.  Before, there was a certain chance to affect
unwanted files.



If I got this correctly, then the folks to benefit from this change
are GUI users, using copy-and-paste. Is this an argument to affect
the command line users?

BTW, apparently the shell quoting-style in coreutils 8.26 (Stretch)
misses to properly quote iso8859 chars, e.g. German Umlaute. Sample:

% ls --quoting-style=shell -al /tmp/Qual*
-rw-r--r-- 1 root root 0 Feb 13 08:27 '/tmp/Qualit?tssicherung final'

Using copy-and-paste, how would you proceed in this case?

I don't want to argue against the usefulness of --quoting-style in
certain cases, but I don't see a reason to change the default yet.
Keep it simple.


Regards
Harri

Re: ls is broken, what's next cd?

[Eric Blake]

On 02/07/2018 01:58 PM, Michael wrote:
Earlier someone suggested something along the line of 
--format="something different" and I believe also an environment 
variable for changing the default layout. An environment variable would 
even mean each user could choose their own (and no environment variable, 
no formatting arguments, etc. and even old dogs like myself are content 


That environment variable already exists: QUOTING_STYLE.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: ls is broken, what's next cd?

[Bernhard Voelker]

On 02/07/2018 07:34 PM, Michael wrote:

I have normal names.


So why and how are you affected?

  $ touch nice-file other-filer

  $ mkdir nice-dir other-dir

  $ \ls -log
  total 8
  drwxr-xr-x 2 4096 Feb  8 00:40 nice-dir
  -rw-r--r-- 10 Feb  8 00:39 nice-file
  drwxr-xr-x 2 4096 Feb  8 00:40 other-dir
  -rw-r--r-- 10 Feb  8 00:39 other-filer

Have a nice day,
Berny

Re: ls is broken, what's next cd?

[Bernhard Voelker]

On 02/07/2018 10:12 AM, Harald Dunkel wrote:

I wonder who is supposed to benefit from this change? For a
human eye these constructs are simply unrecognizable, unless
you look*very*  closely.


There's no change for directories without special file names:

  $ \ls -log
  total 164
  drwxr-xr-x 2   4096 Feb  5 20:23 d
  drwxr-xr-x 2 155648 Jan 28 19:22 d1
  -rw-r--r-- 1  0 Feb  8 00:28 file
  drwxr-xr-x 2   4096 Jan 28 19:22 mnt

... but once you introduce such a file it will be recognized
immediately:

  $ touch 'a b'

  $ \ls -log
  total 164
  -rw-r--r-- 1  0 Feb  8 00:29 'a b'
  drwxr-xr-x 2   4096 Feb  5 20:23  d
  drwxr-xr-x 2 155648 Jan 28 19:22  d1
  -rw-r--r-- 1  0 Feb  8 00:28  file
  drwxr-xr-x 2   4096 Jan 28 19:22  mnt

This is nice IMO.
Your example was quite extreme, and therefore it's clear that
the listing would be hard to read in any style of ls output;
but: the new one can at least be used for copy/paste  ... without
any ambiguity.  Before, there was a certain chance to affect
unwanted files.

Have a nice day,
Berny

Re: ls is broken, what's next cd?

[Jeffrey Walton]

On Wed, Feb 7, 2018 at 1:34 PM, Michael  wrote:
> On 06/02/2018 20:16, Kaz Kylheku (Coreutils) wrote:
>>...
 no, as explained it does not affect programs and scripts, because this
 only changes the output to the terminal.
>>>
>>> Yes, I thought about that too. So, maybe I would have liked the choice
>>> to be able to have them quoted IF and/or WHEN I needed to cut/paste
>>> names. But now I must either not install coreutils (as I have that
>>> option) or always remember to add three characters (' -N') everytime I
>>> want normal ls output.
>>
>> Are you saying that even names without spaces are being quoted?
>
> No. Did not say that. But I hope they are - for consistencies sake. My
> complaint, as such, is about changing the default behavior, not about having
> an "option" to display filenames with quoting characters.

Perhaps a configure option would be a good compromise to provide both
behaviors for those who want want it/don't want it. Choice is usually
a good thing.

Jeff

Re: ls is broken, what's next cd?

[Michael]

On 06/02/2018 20:16, Kaz Kylheku (Coreutils) wrote:

On 2018-02-06 01:30, Michael wrote:

On 06/02/2018 08:13, Bernhard Voelker wrote:

On 02/06/2018 12:41 AM, Michael Felt wrote:
imho, the main problem is you change the default behavior, and 43 
years

of programs are broken.


no, as explained it does not affect programs and scripts, because this
only changes the output to the terminal.


Yes, I thought about that too. So, maybe I would have liked the choice
to be able to have them quoted IF and/or WHEN I needed to cut/paste
names. But now I must either not install coreutils (as I have that
option) or always remember to add three characters (' -N') everytime I
want normal ls output.


Are you saying that even names without spaces are being quoted?
No. Did not say that. But I hope they are - for consistencies sake. My 
complaint, as such, is about changing the default behavior, not about 
having an "option" to display filenames with quoting characters.


If you only see these quotes for idiotic file names, then there is
really no issue.

Nobody should even listen to your complaint, because it is
prompted by the fact that you have such names in your filesystem,


what such names? I have normal names. My complaint is about Human 
Factors - and changing the defaults.




which automatically makes you wrong in that same face of 43 years
of Unix alluded to upthread.

I'm ideologically opposed to this -N thing myself, or anything
which caters to these ill-conceived file names.
I believe it is the opposite: -N (for Normal? with a capital N!), 
whereas the new default caters to 'ill-conceived file names'.


However, practically speaking, sometimes professionals who
do not themselves name things that way can fall "victim" to
people who do. If you have to deal with someone else's filesystem
or tarball or whatever, it does behoove you if your ls disambiguates
things for you.

I have dealt with such issues since 1979 (so only 38+ years) without 
such assistance.


Good day all! May 'ls' be with you!