[TUHS] Command line options and complexity

[Steve Nickolas]

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

-uso.