[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#49716: no -print0 for ls?

From: Pádraig Brady
Subject: bug#49716: no -print0 for ls?
Date: Mon, 26 Jul 2021 16:00:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Thunderbird/84.0

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 


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]