12 Mar
2020
12 Mar
'20
5:14 a.m.
On Wed, Mar 11, 2020 at 6:57 PM Greg 'groggy' Lehey <grog(a)lemis.com>
wrote:
On Wednesday, 11 March 2020 at 14:18:08 +1100, Dave
Horsfall wrote:
I don't know; that's subjective.
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? 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.
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.
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.