1 Aug
2021
1 Aug
'21
12:56 a.m.
Am Sat, 31 Jul 2021 10:30:18 -0700
schrieb Anthony Martin <ality(a)pbrane.org>:
Michael Siegel <msi(a)malbolge.net> once said:
Thanks for pointing this out. I had no idea.
Unfortunately(?), I'm looking to make my life easier on more "Unix-like
Unix-like systems" (for want of a better term), for the time being
(Linux, BSD, maybe illumos). (I mean, which shell would I use to
accomplish this on Unix?) And, as has already been pointed out, this
approach doesn't allow for global command options before sub-commands,
which pretty much defeats the sub-command approach altogether UI-wise,
I'd say.
Unrelated: I'm still having some technical difficulties with this list,
namely that I don't receive any mail sent to it. (I'm using the Web
archive to keep track of what's happening.) So, for me to be able to
reply to a particular message, it would also have to be sent directly
to me. Sorry for the inconvenience. The problem is already being
worked on.
--
Michael
So, I've prepared a bit of a write-up,
pondering on the pros and
cons of two different ways of having task-specific tool sets
(non-hierarchical command sets vs. sub-commands) that is available
at
https://www.msiism.org/files/doc/unix-like_command-line_interfaces.html
I tend to think the sub-command approach is better. But I'm neither
a UI nor a Unix expert and have no formal training in computer
things. So, I thought this would be a good place to ask for comment
(and get some historical perspective).
You're missing the approach taken in Plan 9 (and
10th edition Unix): put related commands in a
directory and use a shell that doesn't restrict
the first argument of a command to a single path
element.
This lets you execute commands like:
auth/as
disk/prep
git/rebase
ip/ping
ndb/dns
upas/send
without having a prefix on every command name or
single large binaries with every command linked
in as subcommands.