GNU bug report logs - #25078
ls-quotes: discrepancy between `ls' and `ls -1'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25078 in the body.
You can then email your comments to 25078 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Zhiming Wang <zmwangx <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: ls 8.26: discrepancy between `ls' and `ls -1' in the alignment of
 quoted and nonquoted items
Date: Wed, 30 Nov 2016 15:19:00 -0500

coreutils 8.26 includes the following improvement:

> ls now aligns quoted items with non quoted items, which is easier to read,
> and also better indicates that the quote is not part of the actual name.

which I find to be a welcome addition to the quoting behavior introduced in
8.25. However, this improvement does not apply to the -1 option, which is
puzzling to me. Compare the following (coreutils 8.26 on macOS 10.12.1,
80-column terminal, bash or zsh):

    $ ls
    '['
    'a very very very very very very very very very very very very long filename'
     b2sum
     base32
     base64
     basename

    $ ls -1
    '['
    'a very very very very very very very very very very very very long filename'
    b2sum
    base32
    base64
    basename

The second invocation with the -1 option leaves much to be desired in
comparison to the first invocation.

-1 should probably receive the same alignment treatment?

Best,
Zhiming

Message #8 received at 25078 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Zhiming Wang <zmwangx <at> gmail.com>, 25078 <at> debbugs.gnu.org
Subject: Re: bug#25078: ls 8.26: discrepancy between `ls' and `ls -1' in the
 alignment of quoted and nonquoted items
Date: Wed, 30 Nov 2016 21:35:49 +0000

On 30/11/16 20:19, Zhiming Wang wrote:
> coreutils 8.26 includes the following improvement:
> 
>> ls now aligns quoted items with non quoted items, which is easier to read,
>> and also better indicates that the quote is not part of the actual name.
> 
> which I find to be a welcome addition to the quoting behavior introduced in
> 8.25.

Cool, thanks.

> However, this improvement does not apply to the -1 option, which is
> puzzling to me. Compare the following (coreutils 8.26 on macOS 10.12.1,
> 80-column terminal, bash or zsh):
> 
>     $ ls
>     '['
>     'a very very very very very very very very very very very very long filename'
>      b2sum
>      base32
>      base64
>      basename
> 
>     $ ls -1
>     '['
>     'a very very very very very very very very very very very very long filename'
>     b2sum
>     base32
>     base64
>     basename
> 
> The second invocation with the -1 option leaves much to be desired in
> comparison to the first invocation.
> 
> -1 should probably receive the same alignment treatment?

I originally had that but thought it might be more problematic than useful.

When `ls -1` is used interactively it can be handy to triple click to
select the whole line, in which case selecting just the file name without
leading space would be preferred.

Also one can use `ls -1 | less` etc. in "interactive" mode, in which case
ls couldn't use alignment or it would break lots of scripts, but then
the output would be inconsistent if alignment was used without the pipe.

Also one can achieve the desired output with `ls -w1` or `ls -x -w1 | less`.

The arguments aren't very strong for not aligning `ls -1` by default,
so we may change this.

thanks,
Pádraig

Message #11 received at 25078 <at> debbugs.gnu.org (full text, mbox):

From: Zhiming Wang <zmwangx <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 25078 <at> debbugs.gnu.org
Subject: Re: bug#25078: ls 8.26: discrepancy between `ls' and `ls -1' in the
 alignment of quoted and nonquoted items
Date: Wed, 30 Nov 2016 16:48:01 -0500

> On Nov 30, 2016, at 4:35 PM, Pádraig Brady <P <at> draigBrady.com> wrote:
> 
> When `ls -1` is used interactively it can be handy to triple click to
> select the whole line, in which case selecting just the file name without
> leading space would be preferred.

I had this thought as well because I've been triple clicking ls output a
lot since 8.25, but then I realized when the filename is one single blob
that doesn't need quoting, I can (at least in my terminal emulator) just
double click to select it anyway, so it doesn't really matter.

> Also one can use `ls -1 | less` etc. in "interactive" mode, in which case
> ls couldn't use alignment or it would break lots of scripts, but then
> the output would be inconsistent if alignment was used without the pipe.

Yeah, that's a valid argument.

> Also one can achieve the desired output with `ls -w1` or `ls -x -w1 | less`.

Didn't think of `ls -w1`. I'll use that, thanks.

Best,
Zhiming

Message #14 received at 25078 <at> debbugs.gnu.org (full text, mbox):

From: Paul Vint <pjvint <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 25078 <at> debbugs.gnu.org, Zhiming Wang <zmwangx <at> gmail.com>
Subject: Re: bug#25078: ls 8.26: discrepancy between `ls' and `ls -1' in the
 alignment of quoted and nonquoted items
Date: Wed, 30 Nov 2016 20:41:45 -0500

[Message part 1 (text/plain, inline)]

The alignment change is helpful, but I do have an argument against doing
the same in the -1 case:
It breaks something many of us have done in scripts.

Of course we *know* that ls -1 isn't the best way to go, but for quickie
scripts it has been the standby for many. Also, I cannot come up with a
good reason why someone would use ls -1 unless they were scripting it. (add
to that, if anyone using the -1 argument that seems to imply that they know
what they are doing). Having said that, I am thinking about it now an know
that I have used ls-1 before just to see the output, and I used it to see
the honest output without any "noise" - no dates and times, no formatting,
no anything, just plain filenames. I think the "list one file per line." in
the man page says it right; just list it.

I understand when you say "The arguments aren't very strong for not
aligning `ls -1` by default,", however I have given you one (albeit weak)
argument, and for me, I cannot see a strong argument for making ls -1 align
like that. As eluded to above, I cannot think of a scenario where someone
would use ls -1 and want it indented for them.

Cheers,
Paul

On Wed, Nov 30, 2016 at 4:35 PM, Pádraig Brady <P <at> draigbrady.com> wrote:

> On 30/11/16 20:19, Zhiming Wang wrote:
> > coreutils 8.26 includes the following improvement:
> >
> >> ls now aligns quoted items with non quoted items, which is easier to
> read,
> >> and also better indicates that the quote is not part of the actual name.
> >
> > which I find to be a welcome addition to the quoting behavior introduced
> in
> > 8.25.
>
> Cool, thanks.
>
> > However, this improvement does not apply to the -1 option, which is
> > puzzling to me. Compare the following (coreutils 8.26 on macOS 10.12.1,
> > 80-column terminal, bash or zsh):
> >
> >     $ ls
> >     '['
> >     'a very very very very very very very very very very very very long
> filename'
> >      b2sum
> >      base32
> >      base64
> >      basename
> >
> >     $ ls -1
> >     '['
> >     'a very very very very very very very very very very very very long
> filename'
> >     b2sum
> >     base32
> >     base64
> >     basename
> >
> > The second invocation with the -1 option leaves much to be desired in
> > comparison to the first invocation.
> >
> > -1 should probably receive the same alignment treatment?
>
> I originally had that but thought it might be more problematic than useful.
>
> When `ls -1` is used interactively it can be handy to triple click to
> select the whole line, in which case selecting just the file name without
> leading space would be preferred.
>
> Also one can use `ls -1 | less` etc. in "interactive" mode, in which case
> ls couldn't use alignment or it would break lots of scripts, but then
> the output would be inconsistent if alignment was used without the pipe.
>
> Also one can achieve the desired output with `ls -w1` or `ls -x -w1 |
> less`.
>
> The arguments aren't very strong for not aligning `ls -1` by default,
> so we may change this.
>
> thanks,
> Pádraig
>
>
>
>
>

[Message part 2 (text/html, inline)]

Message #17 received at 25078 <at> debbugs.gnu.org (full text, mbox):

From: Zhiming Wang <zmwangx <at> gmail.com>
To: Paul Vint <pjvint <at> gmail.com>
Cc: 25078 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigbrady.com>
Subject: Re: bug#25078: ls 8.26: discrepancy between `ls' and `ls -1' in the
 alignment of quoted and nonquoted items
Date: Wed, 30 Nov 2016 21:12:07 -0500

On Nov 30, 2016, at 8:41 PM, Paul Vint <pjvint <at> gmail.com> wrote:
> The alignment change is helpful, but I do have an argument against doing the
> same in the -1 case: It breaks something many of us have done in scripts.

It breaks nothing. Quoting and alignment by default only happens when stdout is
a tty. Also, ls prints one entry per line when stdout is not a tty; you don't
even need -1.

> Of course we *know* that ls -1 isn't the best way to go, but for quickie
> scripts it has been the standby for many.

Parsing ls output not only "isn't the best way", it's also wrong (tm). You know
that, but I still want to point it out. Not saying compatibility should be
broken; as already said, nothing is broken.

> Also, I cannot come up with a good
> reason why someone would use ls -1 unless they were scripting it.

Pádraig already mentioned one: "When `ls -1` is used interactively it can be
handy to triple click to select the whole line." Also, one per line is easier
on my eyes.

> (add to that, if anyone using the -1 argument that seems to imply that they
> know what they are doing).

Not sure what you're implying.

> Having said that, I am thinking about it now an know that I have
> used ls-1 before just to see the output, and I used it to see the honest output
> without any "noise" - no dates and times, no formatting, no anything, just
> plain filenames. I think the "list one file per line." in the man page says it
> right; just list it.

That's more of an argument against quoting than alignment. You should probably
open a new discussion (and you've had quite a while to do that).

> As eluded to above, I cannot think of a scenario where someone would use ls
> -1 and want it indented for them.

The fact that I even bothered to open this issue probably says something about
someone wanting to use `ls -1` and see the results aligned.

Best,
Zhiming

Message #24 received at 25078-done <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Zhiming Wang <zmwangx <at> gmail.com>, Paul Vint <pjvint <at> gmail.com>
Cc: 25078-done <at> debbugs.gnu.org
Subject: Re: bug#25078: ls 8.26: discrepancy between `ls' and `ls -1' in the
 alignment of quoted and nonquoted items
Date: Thu, 13 Dec 2018 13:27:43 -0700

Hello,

On 2016-11-30 7:12 p.m., Zhiming Wang wrote:
> On Nov 30, 2016, at 8:41 PM, Paul Vint <pjvint <at> gmail.com> wrote:
>> The alignment change is helpful, but I do have an argument against doing the
>> same in the -1 case: It breaks something many of us have done in scripts.
> 
> It breaks nothing. Quoting and alignment by default only happens when stdout is
> a tty. Also, ls prints one entry per line when stdout is not a tty; you don't
> even need -1.

We created a summary of common issues and FAQs
regarding the quoting change in ls(1):
  https://www.gnu.org/software/coreutils/quotes.html

If there is an issue that is not addressed there,
please send an email to coreutils <at> gnu.org .

regards,
 - assaf

Message #27 received at 25078-done <at> debbugs.gnu.org (full text, mbox):

From: Zhiming Wang <zmwangx <at> gmail.com>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: Paul Vint <pjvint <at> gmail.com>, 25078-done <at> debbugs.gnu.org
Subject: Re: bug#25078: ls 8.26: discrepancy between `ls' and `ls -1' in the
 alignment of quoted and nonquoted items
Date: Thu, 13 Dec 2018 19:18:34 -0500

On Dec 13, 2018, at 3:27 PM, Assaf Gordon <assafgordon <at> gmail.com> wrote:
> 
> We created a summary of common issues and FAQs
> regarding the quoting change in ls(1):
>  https://www.gnu.org/software/coreutils/quotes.html
> 
> If there is an issue that is not addressed there,
> please send an email to coreutils <at> gnu.org .

This is a pretty informative page, well done. I have two issues with it:

- The page doesn't seem to be linked from anywhere; not the coreutils FAQ, not
  the manual. So discoverability seems rather poor?

- Under "The quotes break my scripts! This is a serious regression.", there's a
  link to https://bugs.gnu.org/25388#11, which is a rant with some
  misinformation and barely even touches breaking scripts (it does touch piping
  to be fair, but again even that part is misinformation-ridden), so it's
  rather confusing. Is it a conscious decision or maybe the wrong post is
  linked?

Message #30 received at 25078 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Zhiming Wang <zmwangx <at> gmail.com>
Cc: 25078 <at> debbugs.gnu.org
Subject: Re: bug#25078: ls 8.26: discrepancy between `ls' and `ls -1' in the
 alignment of quoted and nonquoted items
Date: Sat, 15 Dec 2018 13:52:24 -0700

Hello,

On 2018-12-13 5:18 p.m., Zhiming Wang wrote:
> 
> On Dec 13, 2018, at 3:27 PM, Assaf Gordon <assafgordon <at> gmail.com> wrote:
>>
>>   https://www.gnu.org/software/coreutils/quotes.html

> 
> - The page doesn't seem to be linked from anywhere; not the coreutils FAQ, not
>    the manual. So discoverability seems rather poor?

Initially we'll mention it in replies that directly address this issue.
After a bit more feedback, we might link it in the main page (similar to 
the FAQ).

> - Under "The quotes break my scripts! This is a serious regression.", there's a
>    link to https://bugs.gnu.org/25388#11, which is a rant with some
>    misinformation and barely even touches breaking scripts 

Thanks, I changed it to a different message in the same thread.

regards,
 - assaf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.