[Toybox] [PATCH] ls -N.

[Rob Landley]

On 12/1/22 14:32, enh wrote:
> 
> 
> On Thu, Dec 1, 2022 at 12:21 PM Rob Landley <rob at landley.net
> <mailto:rob at landley.net>> wrote:
> 
>     On 12/1/22 14:17, Rob Landley wrote:
>     > Anyway, applied, I should squint at it more after lunch...
> 
>     Except:
> 
>       $ ls -Nb | wc
>           274     274    4075
>       $ ./toybox ls -Nb
>       ls: No 'b' with 'N' (see "ls --help")
> 
>     It's not [!Nb] it's [-Nb] which means the test setting FLAG_b if we have a tty
>     should test if (!FLAG(N)) and _what_ is show-control-chars doing:
> 
>            --show-control-chars
>                   show nongraphic characters as-is (the default, unless program is
>                   'ls' and output is a terminal)
> 
> 
> (warning: sensitive viewers may want to look away now.)
>  
> 
>     When is program NOT 'ls' in the man page for ls? 
> 
> 
> when it's dir(1) for the ex-DOS crowd 🤢
>  
> 
>     Meanwhile, upstream debian grew
>     a new mode and instead of -b is defaulting to that new one, so my torture test
>     dir looks like:
> 
>       $ ls
>        BE    ̡͔O͟N͎E             'one two four'    ̹̭͟ͅON͏̖͖̹LY̘͓
>        C̷͉̻A̛̜̜͉n  'one'$'\t''two'  'one two three'   T̹̳H̳eRȨ̮̖̤
>       $ ls -b
>       BE  C̷͉̻A̛̜̜͉n  ̡͔O͟N͎E  one\ttwo  one\ two\ four  one\ two\ three  ̹̭͟ͅON͏̖͖̹LY̘͓  T̹̳H̳eRȨ̮̖̤
> 
>     Which I have been STUDIOUSLY IGNORING since it happened. (I actually hate it,
>     because it means most big dirty directories that display as a single column
>     because they have a long name somewhere but ALSO have something with a space in
>     the name somewhere wind up gratuitously indented one space, and you can't make
>     it stop without an "alias" to get the old behavior back.)
> 
> 
> yeah, that annoyed me when i first saw it. i still don't really understand the
> motivation either. unless they're just giving me another reason to have toybox
> higher up my $PATH :-)

I suspect there's some variant of

  for i in $(ls); do echo "$i"; done

For which this is useful, but honestly: just do "ls -z" with null terminators
like EVERYTHING ELSE DOES already. (The two characters the Linux VFS will not
allow to exist in filenames are / and NUL.)

> there's also the `--quoting-style=` section of the info page, where there's a
> bunch of stuff that _sounds_ useful, but i assume based on past experience is
> likely to be similarly annoying in practice.

I did a thorough reading of both the spec and the man page when I implemented
ls. But it's changed since. I was much happier when gnu development was so
throughly dead that when their website got hacked and _I_ was the first one to
notice:

https://developers.slashdot.org/story/03/08/13/1530239/fsf-ftp-site-cracked-looking-for-md5-sums

I first got involved with this stuff back in the "egcs has taken over from gcc"
period, back when bzip2 support for tar was an out of tree patch applied by all
the distros for something like 5 years but not present in raw gnu sources. This
meant gnu wasn't a moving target. (And rightly so, RMS ain't Ken or Dennis.
We're all still basically building apps on top of a lightly updated Unix v7.
It's the "lightly updated" we're arguing about here. Posix's "current" release
being 14 years old plus typos (although they insist they're close to issue 8,
and have so insisted for at least 3 years now) seems about right in that
context. We shouldn't swap CPU instruction sets annually either. I _like_
building new things with old tools, it lets you focus on the things not the tools.)

>     --quote-name which is the new nonsense they added and made the default. They
>     used up the -Q character for something else LONG AFTER adding
>     --hide-control-chars without a corresponding short opt because gnu.
> 
> (as we determined years ago, "this is what happens when 'design' is done by
> drive-by commits".)

Could be worse. Could be systemd.
 
Ok, NOW lunch.

Rob