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=-1.1 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32320 invoked from network); 31 Jul 2021 13:12:23 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 31 Jul 2021 13:12:23 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 4B2AB9CA48; Sat, 31 Jul 2021 23:12:20 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 488089C9B2; Sat, 31 Jul 2021 23:11:55 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id A59959C9B2; Sat, 31 Jul 2021 23:11:51 +1000 (AEST) X-Greylist: delayed 360 seconds by postgrey-1.36 at minnie.tuhs.org; Sat, 31 Jul 2021 23:11:49 AEST Received: from smtp115.iad3a.emailsrvr.com (smtp115.iad3a.emailsrvr.com [173.203.187.115]) by minnie.tuhs.org (Postfix) with ESMTPS id AC4079C9AF for ; Sat, 31 Jul 2021 23:11:49 +1000 (AEST) X-Auth-ID: halbert@halwitz.org Received: by smtp23.relay.iad3a.emailsrvr.com (Authenticated sender: halbert-AT-halwitz.org) with ESMTPSA id EBD3623A06 for ; Sat, 31 Jul 2021 09:05:47 -0400 (EDT) To: tuhs@minnie.tuhs.org References: <20210731142533.69caf929@moon> From: Dan Halbert Message-ID: <146ddec4-af34-dadb-65d0-1f8c309526ae@halwitz.org> Date: Sat, 31 Jul 2021 09:05:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210731142533.69caf929@moon> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Classification-ID: dc8a680a-23a7-4ae7-83c4-de031b6c748d-1-1 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" The "click" CLI parser for Python I think would be of interest to you: https://click.palletsprojects.com/. It has support for sub-commands and nesting. It's not grammar-based internally, as far as I know. Also I think PowerShell has some interesting concepts, though I've not looked at it in detail. Dan H. On 7/31/21 8:25 AM, Michael Siegel wrote: > Hello, > > I've recently started to implement a set of helper functions and > procedures for parsing Unix-like command-line interfaces (i.e., POSIX + > GNU-style long options, in this case) in Ada. > > While doing that, I learned that there is a better way to approach > this problem – beyond using getopt(s) (which never really made sense to > me) and having to write case statements in loops every time: Define a > grammar, let a pre-built parser do the work, and have the parser > provide the results to the program. > > Now, defining such a grammar requires a thoroughly systematic approach > to the design of command-line interfaces. One problem with that is > whether that grammar should allow for sub-commands. And that leads to > the question of how task-specific tool sets should be designed. These > seem to be a relatively new phenomenon in Unix-like systems that POSIX > doesn't say anything about, as far as I can see. > > 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). > > This is all just my pro-hobbyist attempt to make some people's lives > easier, especially mine. I mean, currently, the "Unix" command line is > quite a zoo, and not in a positive sense. Also, the number of > well-thought-out command-line interfaces doesn't seem to be a growing > one. But I guess that could be changed by providing truly easy ways to > make good interfaces. > > > -- > Michael