[TUHS] Command line options and complexity

[Greg 'groggy' Lehey]

On Wednesday, 11 March 2020 at 19:14:32 -0400, Dan Cross wrote:
> On Wed, Mar 11, 2020 at 6:57 PM Greg 'groggy' Lehey <grog at 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.

It's certainly more work than -h.

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

What I meant (and this is certainly my interpretation) was that
somebody added the -h option because of perceived pain with piping
output through another program.  I didn't intend to imply that it was
the only alternative.

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

Yes, that sounds like an excellent method.

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

And yes, I deliberately didn't mention this option, though it occurred
to me.  I have a couple of scripts like this, like:

    alias l="ls -lbL,"

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

Yes, this is an issue that I mentioned in an earlier message (I added
a positional parameter to work around it).  But this is in the nature
of the output.  mc doesn't have this issue.

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

Heh.  Never thought of that.  But since -h (apparently) never produces
output with 4 digits, the -, doesn't ever come into effect.  I've just
tried it on some big files, and the -, is effectively ignored.

> And then there's the question why you don't like the standard
> output.

I don't like the standard output because things like this are hard to
read:

  -rw-r--r--  1 grog  lemis   8234010624 22 Mar  2012 Casanova-TV-1-5
  -rw-r--r--  1 grog  home   13225168900 31 Aug  2019 Movie:_Sahara_2005-2016-04-11-2028

I find this easier to read:

  -rw-r--r--  1 grog  lemis   8,234,010,624 22 Mar  2012 Casanova-TV-1-5
  -rw-r--r--  1 grog  home   13,225,168,900 31 Aug  2019 Movie:_Sahara_2005-2016-04-11-2028

I can't speak for Dave, but this is also less painful:

  -rw-r--r--  1 grog  lemis   7.7G 22 Mar  2012 Casanova-TV-1-5
  -rw-r--r--  1 grog  home     12G 31 Aug  2019 Movie:_Sahara_2005-2016-04-11-2028

The problem for me there is the difficulty comparing lengths, and the
implicit inaccuracy.

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

Hmm.  In this particular case, so does Linux:

  === grog at bilbo (/dev/pts/11) ~ 2 -> touch "foo   "
  === grog at bilbo (/dev/pts/11) ~ 4 -> l foo*
  -rw-r--r-- 1 grog grog 1499570 Jun 30  2012  foo
  -rw-r--r-- 1 grog grog       0 Mar 12 10:40 'foo   '

I wonder if that's something we should emulate in FreeBSD.  At the
very least we should consider whether the lack of identification of
trailing blanks is a bug in the FreeBSD implementation of -B.  This
option isn't in POSIX, and in Linux it means

     -B, --ignore-backups
              do not list implied entries ending with ~

So maybe it's a candidate for fixing.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200312/e4476a64/attachment-0001.sig>