Re: [TUHS] Command line options and complexity

[Dan Cross <crossd@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3408 bytes --]

On Wed, Mar 11, 2020 at 6:57 PM Greg 'groggy' Lehey <grog@lemis.com> wrote:

> On Wednesday, 11 March 2020 at 14:18:08 +1100, Dave Horsfall wrote:
> >
> > The "ls" command for example really needs an option-ectomy; I find that I
> > don't really care about the exact number of bytes there are in a file as
> > the nearest KiB or MiB (or even GiB) is usually good enough, so I'd be
> > happy if "-h" was the default with some way to turn it off (yes, I know
> > that it's occasionally useful to add them all up in a column, but that
> > won't tell you how many media blocks are required).
>
> A good example.  But you're not removing options, you're just
> redefining them.  In fact I find the -h option particularly emetic, so
> a better choice in removing options would be to remove -h and use a
> filter to mutilate the sizes:
>
>   $ ls -l | humanize
>
> But that's a pain, isn't it?


I don't know; that's subjective.


> That's why there's a -h option for
> people who like it.


That's incomplete, in that it implies that an option is the only way to
achieve the goal of reducing the perceived pain, but that's not the case.
(Note I'm not saying you intended that as an interpretation, but it's a
reasonable intuition for an intention.)

An interesting counterpoint to this argument is how columnized "ls" is
handled under Plan 9: there is no `-C` option to `ls` there; instead,
there's a general-purpose `mc` filter that figures out the size of the
window it's running in, reads its input, decides how many columns the input
will fit into, and emits it columnized. But yes, it would be a pain to type
`ls | mc` every time one wanted columnized `ls` output, so this is wrapped
up into a shell script called `lc`. Note that this lets you do stuff like,
`lc -l` and see multi-column long listings if the window is wide enough.

I got so used to this from plan9 that I keep an approximation in
$HOME/bin/lc: `exec ls -ACF "$@"`.

For the `humanize` thing, I don't see why one couldn't have an `lh` command
that generated "human-friendly long output from ls."


> Note that you can't do it the other way round:
> you can't get the exact size from -h output.
>

That's true, but now the logic is specialized to ls, and not applicable to
anything else (e.g., du? df? wc, perhaps?). Similarly with `-,`. It is not
general purpose, which is unfortunate.

Granted, combining these things would be a little challenging, but is it
likely that one would want `ls -l,h`? Optimize for the common case, etc....

And then there's the question why you don't like the standard output.
> Because the number strings are too long and difficult to read, maybe?
> That's the rationale for the -, option.
>
> > Quickly now, without looking: which option shows unprintable
> > characters in a filename?  Unless you use it regularly (in which
> > case you have real problems) you would have to look it up; I find
> > that "ls ... | od -bc" to be quicker, especially on filenames with
> > trailing blanks etc (which "-B" won't show).
>
> This is arguably a bug in the -B option.  I certainly don't think the
> pipe notation is quicker.  But it's nice to have both alternatives.


By default, plan9 would quote filenames that had characters that were
special to the shell (there wasn't really the concept of "non-printable
characters in the Unix/TTY sense); this could be disabled by specifying the
`-Q` option.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 4662 bytes --]