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

[Greg Chicares]

On 2020-04-29 13:42, Vadim Zeitlin wrote:
> 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> 
> GC>     Improve 'ls' output
> GC>     
> 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.

I was so delighted to stumble upon a 'find' command that I could
actually understand, and even memorize, that I tried using it in
my everyday work. That's how I discovered the file named:
  'wxWidgets/3rdparty/catch/projects/Where did the projects go.txt'
so this rose turned out to have thorns.

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

Yes, that too.

>  I'd recommend fixing both problems at once by using
> 
>       find . -print0 | xargs -0 ls -ld
> 
> instead.

Commit 36ce5cc2.