11 Mar
2020
11 Mar
'20
9:18 a.m.
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