From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23056 invoked from network); 31 Jul 2021 21:32:39 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 31 Jul 2021 21:32:39 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 3C0E29C9F2; Sun, 1 Aug 2021 07:32:37 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id DD6C09C9B4; Sun, 1 Aug 2021 07:32:11 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="key not found in DNS" (0-bit key; secure) header.d=mail.malbolge.net header.i=@mail.malbolge.net header.b="HwzuXCwu"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 91AD19C9D3; Sun, 1 Aug 2021 07:32:08 +1000 (AEST) Received: from poseidon.malbolge.net (hera.malbolge.net [185.232.68.32]) by minnie.tuhs.org (Postfix) with ESMTPS id ACE9E9C9B2 for ; Sun, 1 Aug 2021 07:32:06 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=_domainkey; bh=1PVcG+f8n vrsCMH+Adpg3nv4XI/Z2tpdsbwx2hb4kx8=; h=references:in-reply-to:subject: cc:to:from:date; d=mail.malbolge.net; b=HwzuXCwu1YpEr/7wMPiNnwyrtbmZ+J 1FpyNKsJZ4OAqWcBo3uP2jfCBjepdclLUWe8VOxCcv6vCk1UBWR2N2XhNGrp97/JlhHuqT 3qfxYtMFzUmc99TM+BVeqXqHct3R7b1j4v40EmcNs+YxIGAFAidIb2fXCGfgmO8KNMRAnS U= Received: from hermes.malbolge.net (hermes.malbolge.net [192.168.123.201]) by poseidon.malbolge.net (OpenSMTPD) with ESMTP id 515979e9; Sat, 31 Jul 2021 23:32:03 +0200 (CEST) Received: from moon (hera.malbolge.net [10.0.11.1]) by hermes.malbolge.net (Postfix) with ESMTPSA id E41481C3A3C; Sat, 31 Jul 2021 23:32:02 +0200 (CEST) Date: Sat, 31 Jul 2021 23:30:22 +0200 From: Michael Siegel To: Clem Cole Message-ID: <20210731233022.0960b76d@moon> In-Reply-To: References: <20210731142533.69caf929@moon> <20210731205609.07e8149f@moon> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [TUHS] Systematic approach to command-line interfaces X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Am Sat, 31 Jul 2021 15:41:17 -0400 schrieb Clem Cole : > On Sat, Jul 31, 2021 at 2:58 PM Michael Siegel > 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