On Thu, 12 Mar 2020, Greg 'groggy' Lehey wrote:
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
I also had something like that in mind, except being British/Australian
I'd spell it with an "s" :-)
But that's a pain, isn't it? That's
why there's a -h option for people
who like it. Note that you can't do it the other way round: you can't
get the exact size from -h output.
Which is why I suggested there be a means to turn it off; I'm becoming a
fan of environment variables to modify the standard behaviour of tools
(but I loathe the Penguin/OS default to use colours).
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.
More than likely; as I approach age 68 I notice that I'm losing some
cognitive facility... I might start using "," and see if I like it, but I
see that the Mac doesn't have it (my Penguin is off the air at the
moment), and having it as an environment variable would be nice.
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.
Agreed; as for the bug I think it comes down to what is meant by an
unprintable character. I certainly remember finding "hidden" set-uid
shells with the name of ".. " etc back when I was going after the
UNSW kiddies with an axe back in the late 70s...
-- Dave