From: Dave Horsfall <dave@horsfall.org>
To: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] Command line options and complexity
Date: Wed, 11 Mar 2020 14:18:08 +1100 (EST) [thread overview]
Message-ID: <alpine.BSF.2.21.9999.2003111342230.64345@aneurin.horsfall.org> (raw)
In-Reply-To: <CAGGBd_pxrbf5EDMB0FcJ01oKRW=1SZhazhdwX3v0fjx8J0A3Xg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]
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
next prev parent reply other threads:[~2020-03-11 3:18 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-03 18:15 Jon Steinhart
2020-03-03 18:44 ` Adam Thornton
2020-03-04 4:11 ` Tyler Adams
2020-03-04 6:03 ` Dave Horsfall
2020-03-04 6:48 ` arnold
2020-03-04 21:17 ` Dave Horsfall
2020-03-05 0:49 ` Lyndon Nerenberg
2020-03-05 20:54 ` Dave Horsfall
2020-03-05 22:01 ` William Cheswick
2020-03-04 21:50 ` Random832
2020-03-04 23:19 ` Steffen Nurpmeso
2020-03-05 6:12 ` Alan D. Salewski
2020-03-04 22:03 ` Random832
2020-03-04 23:25 ` Terry Jones
2020-03-10 23:03 ` Dan Stromberg
2020-03-11 3:18 ` Dave Horsfall [this message]
2020-03-11 4:02 ` Steve Nickolas
2020-03-11 22:56 ` Greg 'groggy' Lehey
2020-03-11 23:14 ` Dan Cross
2020-03-12 0:42 ` Greg 'groggy' Lehey
2020-03-12 0:53 ` Steve Nickolas
2020-03-12 3:09 ` Greg 'groggy' Lehey
2020-03-12 3:34 ` Steve Nickolas
2020-03-13 1:02 ` Greg 'groggy' Lehey
2020-03-12 5:38 ` Dave Horsfall
2020-03-12 6:48 ` Peter Jeremy
2020-03-12 7:37 ` Steve Nickolas
2020-03-12 7:42 ` Warner Losh
2020-03-12 23:57 ` Greg 'groggy' Lehey
2020-03-12 5:22 ` Dave Horsfall
2020-03-12 5:35 ` Steve Nickolas
2020-03-13 0:36 ` Greg 'groggy' Lehey
2020-03-13 11:26 ` Dave Horsfall
2020-03-14 2:13 ` Greg A. Woods
2020-03-14 4:31 ` Greg 'groggy' Lehey
2020-03-04 14:06 Nelson H. F. Beebe
2020-03-04 16:17 ` John P. Linderman
2020-03-04 17:25 ` Bakul Shah
2020-03-05 0:55 ` Rob Pike
2020-03-05 2:05 ` Kurt H Maier
2020-03-05 4:17 ` Ken Thompson via TUHS
2020-03-05 14:53 ` Dan Cross
2020-03-05 21:50 ` Dave Horsfall
2020-03-05 21:56 ` Warner Losh
2020-03-08 5:26 ` Greg 'groggy' Lehey
2020-03-08 5:32 ` Jon Steinhart
2020-03-08 9:30 ` Tyler Adams
[not found] ` <CAC0cEp8eFRkkLTw88WVaKZoKy+qsrhuC8LkzmmsbqtdZgMf8eQ@mail.gmail.com>
[not found] ` <CAEuQd1D7+dfap98AwPo2W41+06prrcVaAWk3Ve-ve0uQ0xBu3Q@mail.gmail.com>
2020-03-09 21:06 ` John P. Linderman
2020-03-09 21:22 ` Kurt H Maier
2020-03-11 17:41 ` John P. Linderman
2020-03-11 21:29 ` Warner Losh
2020-03-12 0:13 ` John P. Linderman
2020-03-12 0:34 ` Chet Ramey
2020-03-12 12:57 ` John P. Linderman
2020-03-12 19:24 ` Steffen Nurpmeso
2020-03-08 9:51 ` Michael Kjörling
2020-03-05 4:57 Doug McIlroy
2020-03-05 22:17 ` Diomidis Spinellis
2020-03-10 16:15 Doug McIlroy
2020-03-10 17:38 ` Dan Cross
2020-03-10 17:44 ` Bakul Shah
2020-03-10 18:09 ` Dan Cross
2020-03-10 18:42 Doug McIlroy
2020-03-10 19:38 ` Dan Cross
2020-03-13 10:45 Dave Horsfall
2020-03-14 4:35 ` Greg 'groggy' Lehey
2020-03-14 19:52 ` John P. Linderman
2020-03-14 20:25 ` Steffen Nurpmeso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.BSF.2.21.9999.2003111342230.64345@aneurin.horsfall.org \
--to=dave@horsfall.org \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).