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