[Top][All Lists]

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

Re: [lmi] [lmi-commits] master 6b3b67f 1/5: Improve 'ls' output

From: Vadim Zeitlin
Subject: Re: [lmi] [lmi-commits] master 6b3b67f 1/5: Improve 'ls' output
Date: Wed, 29 Apr 2020 15:42:29 +0200

On Tue, 28 Apr 2020 21:17:23 -0400 (EDT) Greg Chicares <address@hidden> wrote:

GC> branch: master
GC> commit 6b3b67f01b2113f64ed5b8bdd66863543e5aaa96
GC> Author: Gregory W. Chicares <address@hidden>
GC> Commit: Gregory W. Chicares <address@hidden>
GC>     Improve 'ls' output
GC>     Here, 'ls -ld $(find .)' is preferable to 'ls -lR' because it gives a
GC>     flat list of files, one file per line, making it easier to compare
GC>     permissions between subdirectories. It does however require disabling
GC>     shellcheck warning SC2046 (quoting really isn't wanted here).

 There are several problems with using "ls -ld $(find .)" other than the
shellcheck warning. First one is that the warning is actually justified in
this case and that if we ever have any filenames with spaces in their
names, the command will return an error. Second, arguably more likely to
happen, problem is that in a directory with a lot of files find output
could easily be longer than maximal command line length (which used to be
as low as 4096 bytes, although on my current Debian Buster system "getconf
ARG_MAX" returns 2MiB).

 I'd recommend fixing both problems at once by using

        find . -print0 | xargs -0 ls -ld


GC>     '(cd wherever && some_command)' is better than 'cd' (which makes a
GC>     persistent change) or 'pushd wherever && some_command; popd' (which
GC>     isn't POSIX).

 No disagreement here. FWIW we probably could avoid using cd at all by
using "find -printf '%P\0'", but it doesn't seem worth complicating things
just to get rid of an extra subshell.


Attachment: pgp7qAzojGzyn.pgp
Description: PGP signature

reply via email to

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