GNU bug report logs - #49716
no -print0 for ls?

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 49716 in the body.
You can then email your comments to 49716 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: Vito Caputo <vcaputo <at> pengaru.com>
To: bug-coreutils <at> gnu.org
Subject: no -print0 for ls?
Date: Sat, 24 Jul 2021 00:03:24 -0700

Am I going senile here or does ls really not have a `find -print0`
equivalent?

Thanks,
Vito Caputo

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Vito Caputo <vcaputo <at> pengaru.com>, 49716 <at> debbugs.gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Sat, 24 Jul 2021 14:22:14 +0100

tag 49716 notabug
close 49716
stop

On 24/07/2021 08:03, Vito Caputo wrote:
> Am I going senile here or does ls really not have a `find -print0`
> equivalent?

This was previously discussed as noted at:
https://www.gnu.org/software/coreutils/rejected_requests.html#ls

In summary, ls output is mainly for non programmatic consumption.
Also find also provides this functionality as you say.

thanks,
Pádraig

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Vito Caputo <vcaputo <at> pengaru.com>
Cc: 49716 <at> debbugs.gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Sat, 24 Jul 2021 18:05:10 +0100

On 24/07/2021 17:34, Vito Caputo wrote:
> On Sat, Jul 24, 2021 at 02:22:14PM +0100, Pádraig Brady wrote:
>> On 24/07/2021 08:03, Vito Caputo wrote:
>>> Am I going senile here or does ls really not have a `find -print0`
>>> equivalent?
>>
>> This was previously discussed as noted at:
>> https://www.gnu.org/software/coreutils/rejected_requests.html#ls
>>
>> In summary, ls output is mainly for non programmatic consumption.
>> Also find also provides this functionality as you say.
>>
> 
> This isn't really a satisfactory rationale IMNSHO, and the chain of
> links you just sent me down is basically a bunch of echoing the same
> incredibly weak rationale.
> 
> I recently tripped over this when just wanting to watch a directory of
> video files in ascending file size order.  A simple `ls -Sr | xargs
> mpv` would do the trick, but the filenames turned out to be a real
> mess warranting -0.  Trivial to add -0 to the xargs, but not so for
> the ls command, wasting significant time digging through its man page.
> 
> Are we really expecting a user in this situation to then go read the
> find(1) man page and figure out how to prevent it from recursive
> operation, produce null termination, *and* sort the results by file
> size in ascending order?
> 
> When they already have the exact `ls -Sr` invocation in hand?
> 
> This seems asinine to me, the entire unix philosophy is composable
> utilities and ad-hoc pipelines.  `ls` is arguably the most familiar
> and reflxively used of those utilities.  I see no reason to prevent
> the user from making its output robust against newlines in pipeline
> scenarios like the one described above.  Especially considering a
> patch has already been submitted to add it...

Perhaps it might be useful when ls is just outputting names,
but would be then disallow a -z option with -l,
because -l has various ambiguities in output leading to non obvious programmatic handling issues.

Do your files have '\n' in them?  If not you might try:

  ls -Sr | tr '\n' '\0' | xargs -r0 mpv

thanks,
Pádraig.

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

From: Vito Caputo <vcaputo <at> pengaru.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 49716 <at> debbugs.gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Sat, 24 Jul 2021 09:34:59 -0700

On Sat, Jul 24, 2021 at 02:22:14PM +0100, Pádraig Brady wrote:
> On 24/07/2021 08:03, Vito Caputo wrote:
> > Am I going senile here or does ls really not have a `find -print0`
> > equivalent?
> 
> This was previously discussed as noted at:
> https://www.gnu.org/software/coreutils/rejected_requests.html#ls
> 
> In summary, ls output is mainly for non programmatic consumption.
> Also find also provides this functionality as you say.
> 

This isn't really a satisfactory rationale IMNSHO, and the chain of
links you just sent me down is basically a bunch of echoing the same
incredibly weak rationale.

I recently tripped over this when just wanting to watch a directory of
video files in ascending file size order.  A simple `ls -Sr | xargs
mpv` would do the trick, but the filenames turned out to be a real
mess warranting -0.  Trivial to add -0 to the xargs, but not so for
the ls command, wasting significant time digging through its man page.

Are we really expecting a user in this situation to then go read the
find(1) man page and figure out how to prevent it from recursive
operation, produce null termination, *and* sort the results by file
size in ascending order?

When they already have the exact `ls -Sr` invocation in hand?

This seems asinine to me, the entire unix philosophy is composable
utilities and ad-hoc pipelines.  `ls` is arguably the most familiar
and reflxively used of those utilities.  I see no reason to prevent
the user from making its output robust against newlines in pipeline
scenarios like the one described above.  Especially considering a
patch has already been submitted to add it...

Thanks,
Vito Caputo

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

From: Vito Caputo <vcaputo <at> pengaru.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 49716 <at> debbugs.gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Sat, 24 Jul 2021 10:48:07 -0700

On Sat, Jul 24, 2021 at 06:05:10PM +0100, Pádraig Brady wrote:
> On 24/07/2021 17:34, Vito Caputo wrote:
> > On Sat, Jul 24, 2021 at 02:22:14PM +0100, Pádraig Brady wrote:
> > > On 24/07/2021 08:03, Vito Caputo wrote:
> > > > Am I going senile here or does ls really not have a `find -print0`
> > > > equivalent?
> > > 
> > > This was previously discussed as noted at:
> > > https://www.gnu.org/software/coreutils/rejected_requests.html#ls
> > > 
> > > In summary, ls output is mainly for non programmatic consumption.
> > > Also find also provides this functionality as you say.
> > > 
> > 
> > This isn't really a satisfactory rationale IMNSHO, and the chain of
> > links you just sent me down is basically a bunch of echoing the same
> > incredibly weak rationale.
> > 
> > I recently tripped over this when just wanting to watch a directory of
> > video files in ascending file size order.  A simple `ls -Sr | xargs
> > mpv` would do the trick, but the filenames turned out to be a real
> > mess warranting -0.  Trivial to add -0 to the xargs, but not so for
> > the ls command, wasting significant time digging through its man page.
> > 
> > Are we really expecting a user in this situation to then go read the
> > find(1) man page and figure out how to prevent it from recursive
> > operation, produce null termination, *and* sort the results by file
> > size in ascending order?
> > 
> > When they already have the exact `ls -Sr` invocation in hand?
> > 
> > This seems asinine to me, the entire unix philosophy is composable
> > utilities and ad-hoc pipelines.  `ls` is arguably the most familiar
> > and reflxively used of those utilities.  I see no reason to prevent
> > the user from making its output robust against newlines in pipeline
> > scenarios like the one described above.  Especially considering a
> > patch has already been submitted to add it...
> 
> Perhaps it might be useful when ls is just outputting names,
> but would be then disallow a -z option with -l,
> because -l has various ambiguities in output leading to non obvious programmatic handling issues.
> 

Yes, it only makes sense with plain names in single-column format.

But that usage style has significant applicability... Couldn't we make
-0 and any aliases shorthand for a new --format=WORD where WORD is
names0 or something.  That way it's automatically mutually exclusive
with the other formats?


> Do your files have '\n' in them?  If not you might try:
> 
>   ls -Sr | tr '\n' '\0' | xargs -r0 mpv
> 

There were newlines in some of the names...

It was just one of those situations where you know you have a heap of
crazy web-scraped titles, and you have no interest in making
assumptions about what is or isn't in there.  So you just want
nul-terminated strings and to not fret about anything going awry.

Thanks,
Vito Caputo

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Vito Caputo <vcaputo <at> pengaru.com>, Pádraig Brady
 <P <at> draigBrady.com>
Cc: 49716 <at> debbugs.gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Sat, 24 Jul 2021 12:26:01 -0700

On 7/24/21 10:48 AM, Vito Caputo wrote:
> Couldn't we make
> -0 and any aliases shorthand for a new --format=WORD where WORD is
> names0 or something.  That way it's automatically mutually exclusive
> with the other formats?

It would make sense to invent a new --quoting-style='literal0' option 
(by analogy with the existing --quoting-style='literal'), and make ls -0 
an alias for ls --quoting-style='literal0'. I could add support for that 
if there's interest.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Vito Caputo <vcaputo <at> pengaru.com>
Cc: 49716 <at> debbugs.gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Sun, 25 Jul 2021 15:43:03 +0100

On 24/07/2021 20:26, Paul Eggert wrote:
> On 7/24/21 10:48 AM, Vito Caputo wrote:
>> Couldn't we make
>> -0 and any aliases shorthand for a new --format=WORD where WORD is
>> names0 or something.  That way it's automatically mutually exclusive
>> with the other formats?
> 
> It would make sense to invent a new --quoting-style='literal0' option
> (by analogy with the existing --quoting-style='literal'), and make ls -0
> an alias for ls --quoting-style='literal0'. I could add support for that
> if there's interest.

It's one of those marginal ones I think,
but if you think it's warranted, that's cool.
I would use the more consistent option for this though, i.e.:

  -z, --zero                    end each output line with NUL, not newline

We could document that -z implies:

  --quoting-style=literal --show-control-chars --format=single-column

The --format=single-column implication is debatable.
I'm suggesting it as robust programmatic parsing of --format=long is
pretty much impossible, which is not obvious.

thanks,
Pádraig

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Vito Caputo <vcaputo <at> pengaru.com>
Cc: 49716 <at> debbugs.gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Sun, 25 Jul 2021 08:28:06 -0700

On 7/25/21 7:43 AM, Pádraig Brady wrote:
> I would use the more consistent option for this though, i.e.:
> 
>    -z, --zero                    end each output line with NUL, not newline

That's a different option, no? My proposal was something that would 
affect every program using --quoting-style, and it would quote 
individual filenames and suchlike. The --zero option, in contrast, would 
mean 'ls' would output NUL every place it normally outputs a newline as 
part of the own format that it generates. These are different things.

It sounds like your approach is better than what I proposed, though.

--null makes sense, but I'm not entirely sold on having a short option 
for this rarely-needed functionality. Perhaps it'd be better to add it 
with just the long name for now. If it gets used a lot we could add a 
short alias later.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Sun, 25 Jul 2021 18:10:14 +0100

On 25/07/2021 16:28, Paul Eggert wrote:
> On 7/25/21 7:43 AM, Pádraig Brady wrote:
>> I would use the more consistent option for this though, i.e.:
>>
>>     -z, --zero                    end each output line with NUL, not newline
> 
> That's a different option, no? My proposal was something that would
> affect every program using --quoting-style, and it would quote
> individual filenames and suchlike. The --zero option, in contrast, would
> mean 'ls' would output NUL every place it normally outputs a newline as
> part of the own format that it generates. These are different things.
> 
> It sounds like your approach is better than what I proposed, though.
> 
> --null makes sense, but I'm not entirely sold on having a short option
> for this rarely-needed functionality. Perhaps it'd be better to add it
> with just the long name for now. If it gets used a lot we could add a
> short alias later.

Right we should be especially careful of short options with ls.
A long only option should suffice

cheers,
Pádraig

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Vito Caputo <vcaputo <at> pengaru.com>, 49716 <at> debbugs.gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Mon, 26 Jul 2021 01:05:50 -0700

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

On 7/25/21 10:10 AM, Pádraig Brady wrote:
> Right we should be especially careful of short options with ls.
> A long only option should suffice

OK, I installed the attached to implement 'ls --null'. (The last patch 
is the actual change; the other patches are cleanups.) This addresses 
the problem raised in the bug report.

Is there any pattern as to why some coreutils programs have a --null 
option and others have a --zero option? The two options seem to mean the 
same thing. Should we work toward standardizing on one spelling or the 
other (of course maintaining backward compatibility).

[0001-env-fix-usage-typo.patch (text/x-patch, attachment)]

[0002-maint-fix-white-space.patch (text/x-patch, attachment)]

[0003-build-update-gnulib-submodule-to-latest.patch (text/x-patch, attachment)]

[0004-ls-simplify-sprintf-usage.patch (text/x-patch, attachment)]

[0005-ls-demacroize.patch (text/x-patch, attachment)]

[0006-ls-port-to-wider-off_t-uid_t-gid_t.patch (text/x-patch, attachment)]

[0007-ls-add-null-option-Bug-49716.patch (text/x-patch, attachment)]

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Vito Caputo <vcaputo <at> pengaru.com>, 49716 <at> debbugs.gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Mon, 26 Jul 2021 16:00:46 +0100

On 26/07/2021 09:05, Paul Eggert wrote:
> On 7/25/21 10:10 AM, Pádraig Brady wrote:
>> Right we should be especially careful of short options with ls.
>> A long only option should suffice
> 
> OK, I installed the attached to implement 'ls --null'. (The last patch
> is the actual change; the other patches are cleanups.) This addresses
> the problem raised in the bug report.
> 
> Is there any pattern as to why some coreutils programs have a --null
> option and others have a --zero option? The two options seem to mean the
> same thing. Should we work toward standardizing on one spelling or the
> other (of course maintaining backward compatibility).

The patch set looks good thanks.

Note we were consolidating on --zero rather than --null

  $ grep -l -F -- --zero src/*.c | fmt
  src/basename.c src/comm.c src/cut.c src/dirname.c src/head.c src/id.c
  src/join.c src/md5sum.c src/numfmt.c src/paste.c src/readlink.c
  src/realpath.c src/shred.c src/shuf.c src/sort.c src/tail.c src/uniq.c

  $ grep -l -F -- --null src/*.c | fmt
  src/du.c src/env.c src/ls.c src/printenv.c

So I'd have a slight preference for --zero.

Also what about having --zero imply:
  --quoting-style=literal --show-control-chars --format=single-column
That seems like a fine shortcut given that would be correct in the vast majority of cases,
and that the need for the above may not be obvious to users.

Also a small point; should --dired disable --null as it may then be non parseable?

thanks,
Pádraig.

p.s. I installed a trivial patch to avoid syntax-check issues

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Vito Caputo <vcaputo <at> pengaru.com>, 49716 <at> debbugs.gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Mon, 26 Jul 2021 21:52:26 +0200

On 7/26/21 5:00 PM, Pádraig Brady wrote:
> The patch set looks good thanks.

Wait - I see another reason why we didn't add it earlier:

The --null option is not compatible with about half of the other options of ls(1);
at least the actual output is more than questionable, and not usable in programmatic
context.  The -R option is the first one which obviously can't work as such.

The following options don't work well with --null, because they output other,
additional information or transform/escape the file names:

  -b, --escape               print C-style escapes for nongraphic characters
  -C                         list entries by columns
      --color[=WHEN]         colorize the output; WHEN can be 'always' (default
                               if omitted), 'auto', or 'never'; more info below
  -F, --classify             append indicator (one of */=>@|) to entries
      --file-type            likewise, except do not append '*'
      --full-time            like -l --time-style=full-iso
  -g                         like -l, but do not list owner
      --indicator-style=WORD  append indicator with style WORD to entry names:
                               none (default), slash (-p),
                               file-type (--file-type), classify (-F)
  -i, --inode                print the index number of each file
  -l                         use a long listing format
  -m                         fill width with a comma separated list of entries
  -n, --numeric-uid-gid      like -l, but list numeric user and group IDs
  -o                         like -l, but do not list group information
  -p, --indicator-style=slash
                             append / indicator to directories
  -q, --hide-control-chars   print ? instead of nongraphic characters
  -Q, --quote-name           enclose entry names in double quotes
      --quoting-style=WORD   use quoting style WORD for entry names:
                               literal, locale, shell, shell-always,
                               shell-escape, shell-escape-always, c, escape
                               (overrides QUOTING_STYLE environment variable)
  -R, --recursive            list subdirectories recursively
  -s, --size                 print the allocated size of each file, in blocks
  -x                         list entries by lines instead of by columns
  -Z, --context              print any security context of each file

While the actual change is small - i.e., change the newline to a '\0' for the eolchar,
I'm afraid that it will become quite hairy to discuss the actual problems of future users
of that option when combining it with one of the above options.

I really have some qualms with adding --null to ls(1).  If this is about listing files
in the current directory in a certain sort order for a processing purpose, then this
would IMO warrant a new utility rather than blowing ls(1).

Have a nice day,
Berny

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Pádraig Brady <P <at> draigBrady.com>
Cc: Vito Caputo <vcaputo <at> pengaru.com>, 49716 <at> debbugs.gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Mon, 26 Jul 2021 13:02:31 -0700

On 7/26/21 12:52 PM, Bernhard Voelker wrote:

> The following options don't work well with --null, because they output other,
> additional information or transform/escape the file names:
...
>    -l                         use a long listing format

I don't see a problem with -l, as --null can be a win with -l because 
file names are more-reliably parsed in output from -l --null than they 
are from plain -l.

More generally, I don't see a problem with -F, --file-type, --full-time, 
-g, --indicator-style, -i, -l, -n, -o, -p, -R, -s, or -Z. In all those 
cases it can be a win to use --null so that file names are unambiguous 
and easily parsed.

I do see a problem for -b, -C, --color, -q, -Q, --quoting-style, -x. 
Pádraig made a similar point. I'll look into this and into his other points.

> this
> would IMO warrant a new utility rather than blowing ls(1).

Oh I don't know, ls seems to be a natural home for "Do what 'ls' does, 
except with NUL instead of newline."

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Vito Caputo <vcaputo <at> pengaru.com>, 49716 <at> debbugs.gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Tue, 27 Jul 2021 18:14:31 -0700

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

On 7/26/21 8:00 AM, Pádraig Brady wrote:

> So I'd have a slight preference for --zero.
> 
> Also what about having --zero imply:
>    --quoting-style=literal --show-control-chars --format=single-column
> That seems like a fine shortcut given that would be correct in the vast 
> majority of cases,
> and that the need for the above may not be obvious to users.
> 
> Also a small point; should --dired disable --null as it may then be non 
> parseable?

Thanks, all good suggestions. For --dired vs --zero I thought it better 
simply to prohibit the combination since neither should be in 'ls' shell 
aliases, and prohibiting means we can add it later if we like. I 
installed the attached patches to do this (plus the other stuff I 
mentioned in my reply to Berny).

The first patch is a cleanup because I had a bit of trouble following 
the forest of 'if's inside of ls.c's decode_switches function and I 
thought it better to avoid unnecessary syscalls while I was at it.

The second patch does the real work.

[0001-ls-compute-defaults-more-lazily.patch (text/x-patch, attachment)]

[0002-ls-rename-null-to-zero-Bug-49716.patch (text/x-patch, attachment)]

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Vito Caputo <vcaputo <at> pengaru.com>, 49716 <at> debbugs.gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Wed, 28 Jul 2021 12:57:38 +0100

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

On 28/07/2021 02:14, Paul Eggert wrote:
> On 7/26/21 8:00 AM, Pádraig Brady wrote:
> 
>> So I'd have a slight preference for --zero.
>>
>> Also what about having --zero imply:
>>     --quoting-style=literal --show-control-chars --format=single-column
>> That seems like a fine shortcut given that would be correct in the vast
>> majority of cases,
>> and that the need for the above may not be obvious to users.
>>
>> Also a small point; should --dired disable --null as it may then be non
>> parseable?
> 
> Thanks, all good suggestions. For --dired vs --zero I thought it better
> simply to prohibit the combination since neither should be in 'ls' shell
> aliases, and prohibiting means we can add it later if we like. I
> installed the attached patches to do this (plus the other stuff I
> mentioned in my reply to Berny).
> 
> The first patch is a cleanup because I had a bit of trouble following
> the forest of 'if's inside of ls.c's decode_switches function and I
> thought it better to avoid unnecessary syscalls while I was at it.
> 
> The second patch does the real work.
> 

That all looks great.

I see --zero implies --format=single-column, but allows --format=long.
That's the right default, but also most flexible.

I'll apply the attached later to augment/document the test
with the various supported option combinations.

thanks!
Pádraig

[ls--zero-tests.patch (text/x-patch, attachment)]

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

From: Vito Caputo <vcaputo <at> pengaru.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 49716 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#49716: no -print0 for ls?
Date: Wed, 28 Jul 2021 10:54:24 -0700

On Wed, Jul 28, 2021 at 12:57:38PM +0100, Pádraig Brady wrote:
> On 28/07/2021 02:14, Paul Eggert wrote:
> > On 7/26/21 8:00 AM, Pádraig Brady wrote:
> > 
> > > So I'd have a slight preference for --zero.
> > > 
> > > Also what about having --zero imply:
> > >     --quoting-style=literal --show-control-chars --format=single-column
> > > That seems like a fine shortcut given that would be correct in the vast
> > > majority of cases,
> > > and that the need for the above may not be obvious to users.
> > > 
> > > Also a small point; should --dired disable --null as it may then be non
> > > parseable?
> > 
> > Thanks, all good suggestions. For --dired vs --zero I thought it better
> > simply to prohibit the combination since neither should be in 'ls' shell
> > aliases, and prohibiting means we can add it later if we like. I
> > installed the attached patches to do this (plus the other stuff I
> > mentioned in my reply to Berny).
> > 
> > The first patch is a cleanup because I had a bit of trouble following
> > the forest of 'if's inside of ls.c's decode_switches function and I
> > thought it better to avoid unnecessary syscalls while I was at it.
> > 
> > The second patch does the real work.
> > 
> 
> That all looks great.
> 
> I see --zero implies --format=single-column, but allows --format=long.
> That's the right default, but also most flexible.
> 
> I'll apply the attached later to augment/document the test
> with the various supported option combinations.
> 

I'm a bit busy with non-computer work at the moment (building a roof),
but will try find some time to kick the tires on these changes in the
coming weeks.

Thanks all for considering the issue beyond EWONTFIX.

Cheers,
Vito Caputo

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Vito Caputo <vcaputo <at> pengaru.com>, 49716 <at> debbugs.gnu.org
Subject: Re: bug#49716: no -print0 for ls?
Date: Wed, 28 Jul 2021 12:37:14 -0700

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

On 7/28/21 4:57 AM, Pádraig Brady wrote:
> I see --zero implies --format=single-column, but allows --format=long.
> That's the right default, but also most flexible.

Yes, it's a little tricky here.

For quite some time the ls -1 (digit 1 option) code has disagreed with 
its documentation. The doc said '-1' is equivalent to 
'--format=single-column', but the code makes '-l -1' equivalent to '-l' 
whereas '-l --format=single-column' is equivalent to no option at all.

I see three possible fixes here:

1. Change the doc to match the code, i.e., change the documentation to 
say that -1 is not the same thing as --format=single-column.

2. Change the code so that --format=single-column also has no effect 
after -l, and change the doc to document this.

3. Change the code to match the doc.

(3) would not conform to POSIX, so that's out. (1) is less work for us 
and does not affect existing uses, so I installed the first attached 
patch to implement (1). This first patch also cleans up a bunch of other 
documentation cruft that I noticed in the 'ls' documentation. The second 
patch updates up some old-fashioned terminology I noticed while working 
on the first patch.

You could talk me into (2), I suppose....

[0001-doc-improve-ls-documentation.patch (text/x-patch, attachment)]

[0002-doc-modernize-usage-of-disk-and-core.patch (text/x-patch, attachment)]

Previous Next

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