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

Previous Next

Package: coreutils;

Reported by: Vito Caputo <vcaputo <at> pengaru.com>

Date: Sat, 24 Jul 2021 09:45:02 UTC

Severity: normal

Tags: notabug

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


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."




This bug report was last modified 3 years and 353 days ago.

Previous Next


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