[TUHS] Command line options and complexity
dave at horsfall.org
Wed Mar 11 13:18:08 AEST 2020
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
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"
> 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).
More information about the TUHS