[TUHS] Command line options and complexity

[Dave Horsfall]

On Tue, 10 Mar 2020, Dan Stromberg wrote:

> When I took a comparative languages class in school, the teacher said 
> that the complexity of a programming language varies with the square of 
> its number of features.

That sort of makes sense from a mathematical point of view, if you regard 
it as a matrix of side effects.  I hate to think about how it affects Perl 
(my favourite language) though :-)

> I wonder if it's similar for command line options in shell-callables?

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

> On the other hand, adding command line options was (at least at one 
> time) seen seen as a way of distinguishing GNU tools from Unix tools - 
> that is, they were seen as a way of avoiding the copyright lawsuits that 
> were snipping at BSD's heels.

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

-- Dave