Am Sat, 31 Jul 2021 15:41:17 -0400
schrieb Clem Cole <clemc(a)ccc.com>om>:
On Sat, Jul 31, 2021 at 2:58 PM Michael Siegel
I mean, which shell would I use to accomplish
this on Unix?
In the old days, when the first Unix shell wars started, there was a
Unix adage: *"Bourne to Program, Type with Joy"*
FWIW: tcsh supports TOPS-20 autocomplete -- a little work with your
search engine, you can figure out how to use its many options. That
said, the GNU bash is said to do it also, but I can not say I have
tried it personally since the ROMS in my fingers were long ago burned
to 'Type with Joy.'
I see. I currently use Bash as my shell most of the time, and I have
my doubts about that being a good idea. But I also doubt I would like
tcsh any more. I've had a bit of experience with it on FreeBSD once.
All I can say is: We didn't get along when we first met, and we haven't
met since. The one and only shell I know that is (arguably) both a
traditional Unix shell and a huge improvement on the traditional Unix
shell is rc, which I have recently begun to use on and off. I can see
myself switching to that eventually, even though it lacks some
features I've come to depend on. It's definitely non-standard. But I
don't care about that very much because I believe it's objectively
better, and considerably so.
Also in 50 years, it's so much that UNIX is
perfect, it has lots of
flaws and quirks. Thinking about them and considering 'better'
solutions is often wise, particularly when capabilities (like Moore's
law) give you new tools to solve them. But a level of wisdom here is
not all of those quirks are worth repairing. In the case of
command-line parsing, getopt(3) has proven to be 'good enough' for
most things. If it was really as bad as you seem to think, I suspect
one of the previous N attempts over the last 50 years might have
My point in my previous message was that getopt(3) was created to
solve the original UNIX problem. It did actually take root (I'll not
get into if the Gnu long stuff was an improvement). But there were
other attempts, including the Tops-20 scheme (which has been pointed
out is quite similar to yours) that have been around for at least 35
years in the UNIX community and it did not catch on. I ask you to
think about if maybe your value of that feature might be more than
others have set it to be.
To me, using getopt/getopts has always felt more like a way to
complicate parsing rather than solving any actual problem. My aim
is to get around writing an actual parsing routine based on a
half-backed set of rules each time I put together a command-line utility
because that is time-consuming (for no good reason) and error-prone.
I really find the TOPS-20 way of going about this inspiring, though I'd
aim for something way more primitive that should indeed be good
enough. And I'd want it to stay as close to the POSIX Utility Syntax
Guidelines as reasonably possible because even though these are
lacking, I find them a reasonable base to build upon.
Also, experience tells me that merely adapting to what has taken root is
quite often not a good idea at all. In fact, the reasons for something
good and valuable not taking root might actually turn out to be pretty
As an analog, when I first came to UNIX and C from
ideas like the open curly brace/close curly brace instead of
BEGIN/END in C, and there were plenty of things in Ken's original
shell that I found annoying, particularly coming from the regularity
of TOPS-20 and the like. Hey, I used EMACS, TECO and DDT and none of
them were in my new kit. But I forced myself to learn the new tools
and new way of doing things. Since I was programming on UNIX in C, I
made sure my code looked like everyone else [K&R did not yet exist --
but we would later call this 'White Book C." Why? So someone else
could read it. I learned that style too and frankly have a hard
time with any C code that does not follow it today. But if I am
writing in a BEGIN/END style language, I adopt that style. When in
Rome and all that.
In time, the wonderful things I could do in the UNIX world way
outpaced what I could do in the old world. In fact, by the time
either TECO or EMACS bacame available for my use by then on a Vax, I
never switched off the earlier UNIX tools I had learned. Like I
said, I 'Type with Joy", frankly even if I'm on a Mac, Linux or
Windows -- I switch the shell to be tcsh. Could I learn a new shell,
sure? If I were to switch today, it would probably be zsh, but my
suggestion is to learn the tools that system has really well. They
keep using them. Adapt to the style of the system you are using.
As you'll be able to guess by now, I beg to differ.
For example, I have forced myself to learn POSIX shell and Bash, even
enjoying some of it along the way. Today, I believe that they are both
rather terrible things I don't want to spend too much time with. (That
said, for my use case, Bash is almost always preferable over the
available POSIX sh implementation.) Then, I have always had a strong
dislike for the interface of the Unix `find` command. So, I tried to
replace it with what I thought was a better solution (relatively). That
required me to understand `find` on a whole different level. And after
gaining a much better understanding of `find` (and losing some of my
dislike for it), I still believe it should be replaced and have a few
ideas on how to do that. (Sadly, I mainly just have ideas.)
So, in a nutshell: I think that adapting to something that you believe
to be more than slightly deficient after giving it a try and trying to
understand its logic is not a reasonable thing to do.
Anyway, that my thoughts from an old guy.
They're much appreciated.