[TUHS] Command line options and complexity
usotsuki at buric.co
Wed Mar 11 14:02:29 AEST 2020
On Wed, 11 Mar 2020, Dave Horsfall wrote:
> I'm starting to think that if a utility requires many options then perhaps
> they ought to be split into filters (or at least environment variables); I
> despair at how *ix is drifting from "one tool, one job" to "one size fits
> 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).
> 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).
It would probably be interesting to define a simplified standard, because
yeesh, trying to implement even a command as basic as ls is just torture
(mainly because it basically requires putting all of "column" and most of
"sort" into it)!
> I've never liked GNU's "--bloody-long-option" convention as you still have to
> look up which one does what, but I've never thought about that view; a lot of
> long options still accept a single character (subject to feeping creaturism,
> of course).
I'm still into the one-character switch thing, personally.
More information about the TUHS