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
