1 Aug
2021
1 Aug
'21
7:48 p.m.
On 7/31/21 2:56 PM, Michael Siegel wrote:
Am Sat, 31 Jul 2021 10:30:18 -0700
schrieb Anthony Martin <ality(a)pbrane.org>:
POSIX forbids this behavior, FWIW, so you'll probably have a hard time
finding a shell -- at least one with POSIX aspirations -- that implements it.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
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?) 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.