|
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 sufficeOK, 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
[Prev in Thread] | Current Thread | [Next in Thread] |