[TUHS] Systematic approach to command-line interfaces

[Michael Siegel]

Am Sat, 31 Jul 2021 15:41:17 -0400
schrieb Clem Cole <clemc at ccc.com>:

> On Sat, Jul 31, 2021 at 2:58 PM Michael Siegel <msi at malbolge.net>
> wrote:
> 
> > 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
> taken root.
> 
> 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
nasty.

> As an analog, when I first came to UNIX and C from other systems,
> 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.


--
Michael