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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20957 invoked from network); 31 Jul 2021 16:20:21 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 31 Jul 2021 16:20:21 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id E09F79C9E1; Sun, 1 Aug 2021 02:20:20 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id AAD259C9B2; Sun, 1 Aug 2021 02:20:06 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="sa8Lm4Mi"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id E8AF39C9B2; Sun, 1 Aug 2021 02:20:04 +1000 (AEST) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) by minnie.tuhs.org (Postfix) with ESMTPS id 1E4139C9AF for ; Sun, 1 Aug 2021 02:20:04 +1000 (AEST) Received: by mail-oi1-f175.google.com with SMTP id q6so17978634oiw.7 for ; Sat, 31 Jul 2021 09:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=652e3Au1Ts1OhTUKeDcVI6NCmR+Ptw3wQzrXco3Ptns=; b=sa8Lm4MiHmZb89u0Vuk8bBS0S2pVd6znfnUzjpUeN20qx2eaOj2jR8NuUENEB+aaNe 6bqOvvDlCVeAUN3kYNRPcHVyhCHJR9CuOv7GC2/KkMzModJN8tqRBHvPmpMkAYPk4OpR rUK4a27Hwg6+nmcDmIsJcT1TjDdGp2NuQ6XPup72+f5exC1BxUqw+euHIWIoAwmnLDYU NrpwSb0P3focQL2kRMsdbVhLtKr7nU1YHGVKit5o+p2icjKtzpZAmF+mhZ4RfhIFJHVh 8tpZQmYltAYgrC2RBoOxw57d4Xpq9TMrsp7IU92XMsmHfAQS3txjCLuasorAPwCA82WW zJ6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=652e3Au1Ts1OhTUKeDcVI6NCmR+Ptw3wQzrXco3Ptns=; b=hIyotYHxxbl8kgoH4MpYKxoVOqVYJGHKLWXKt9iKv6XdGqnuhccvDpZFA8169V7cD1 WrnCGaQ+da5kSx+04ZSFeBC09Z+JI0PvHG8Z1syIYl7xZYPrhBaTai0eH5W0FpNcHzAF wlCYGWY/fwu+fHmj9DzMf8/cXp7hVjtR6YAHaNebi7w3nNT7PGSu+Pu1b7DJsGQbVDD5 dZqOz0b8Bj4FK5AxXxBkEn4mEBqcwJd1SINuajRYfdtdD1d1oLq86Hz9yEdUkDxfrIgK SodZuq16NhgSWMp4dx5z2MEaeiUZh7Nd4Arq8KntcZOgM7JWn/4fJL0o8QygK+L1c0mM qRZg== X-Gm-Message-State: AOAM531hErPvHtxwUeNz2CZiZgSBfjTeU4H7JcqAZ+Y56IJ2ck1eK0ht PyHsyJ3mZw7xWd7g33slybn8uKBtO5bz8KcRdDs= X-Google-Smtp-Source: ABdhPJzkJNg/8GsOBXLGqhxa/tdskmHJjZpJleEP9mbVfphLx+f//6VvbZAzf3ufLPbecZ7uuZ6DdYzf94xLJThfKr8= X-Received: by 2002:aca:4c49:: with SMTP id z70mr5374704oia.174.1627748403421; Sat, 31 Jul 2021 09:20:03 -0700 (PDT) MIME-Version: 1.0 References: <20210731142533.69caf929@moon> In-Reply-To: From: Dan Cross Date: Sat, 31 Jul 2021 12:19:27 -0400 Message-ID: To: Paul Winalski Content-Type: multipart/alternative; boundary="0000000000005ea4a605c86db57b" 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" --0000000000005ea4a605c86db57b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 31, 2021 at 11:57 AM Paul Winalski wrote: > On 7/31/21, Michael Siegel wrote: > > > > While doing that, I learned that there is a better way to approach > > this problem =E2=80=93 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. > > This method for handling command lines dates back at least to the > 1970s. The COMND JSYS (system call) in TOPS-20 operated this way, as > does the DCL command line interface in OpenVMS. As you pointed out it > can greatly simplify the code in the application. It also permits > command completion. If the command has a long-winded option, such as > -supercalifragilisticexpialidocious, I can type -super then hit the > TAB key and as long as there is only one option that starts with > -super the parser will fill in the rest of the long keyword. It also > means that you can provide interactive help. At any point the user > can type a question mark and the command interpreter will say what > syntactic element is expected next. The TOPS-20 COMND JSYS > implemented both of these features, and I think that command > completion was eventually added to the VMS command interpreter, too. > > This method of command line parsing also enforces a degree of > uniformity of syntax between the command lines of the various > utilities and applications. > There was someone posting here on TUHS a while back about leveraging a special context-sensitive `--shell-help` or similar command line program and synthesizing a protocol between the shell and a program to provide TOPS-20 like command completion. It was nowhere near what you get from the COMND JSYS, but seemed like a reasonable approximation. This is verging on COFF territory, but one of the reasons such a mechanism is unlike what you get from TOPS-20 is that, in that system, as soon as you type the name of a command, you're effectively running that command; the process model is quite different from that of Unix. With respect to command line handling in general, I think there are some attempts at making things more rational available in modern languages. Command line parsing packages for Go and the `clap` package for Rust come to mind ( https://rust-lang-nursery.github.io/rust-cookbook/cli/arguments.html). I've used clap recently in a few places and it's very convenient. - Dan C. --0000000000005ea4a605c86db57b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 31, 2021 at = 11:57 AM Paul Winalski <paul.winalski@gmail.com> wrote:
On 7/31/21, = Michael Siegel <ms= i@malbolge.net> wrote:
>
> While doing that, I learned that there is a better way to approach
> this problem =E2=80=93 beyond using getopt(s) (which never really made= sense to
> me) and having to write case statements in loops every time: Define a<= br> > grammar, let a pre-built parser do the work, and have the parser
> provide the results to the program.

This method for handling command lines dates back at least to the
1970s.=C2=A0 The COMND JSYS (system call) in TOPS-20 operated this way, as<= br> does the DCL command line interface in OpenVMS.=C2=A0 As you pointed out it=
can greatly simplify the code in the application.=C2=A0 It also permits
command completion.=C2=A0 If the command has a long-winded option, such as<= br> -supercalifragilisticexpialidocious, I can type -super then hit the
TAB key and as long as there is only one option that starts with
-super the parser will fill in the rest of the long keyword.=C2=A0 It also<= br> means that you can provide interactive help.=C2=A0 At any point the user can type a question mark and the command interpreter will say what
syntactic element is expected next.=C2=A0 The TOPS-20 COMND JSYS
implemented both of these features, and I think that command
completion was eventually added to the VMS command interpreter, too.

This method of command line parsing also enforces a degree of
uniformity of syntax between the command lines of the various
utilities and applications.

There was s= omeone posting here on TUHS a while back about leveraging a special context= -sensitive `--shell-help` or similar command line program and synthesizing = a protocol between the shell and a program to provide TOPS-20 like command = completion. It was nowhere near what you get from the COMND JSYS, but seeme= d like a reasonable approximation.

This is verging= on COFF territory, but one of the reasons such a mechanism is unlike what = you get from TOPS-20 is that, in that system, as soon as you type the name = of a command, you're effectively running that command; the process mode= l is quite different from that of Unix.

With respe= ct to command line handling in general, I think there are some attempts at = making things more rational available in modern languages. Command line par= sing packages for Go and the `clap` package for Rust come to mind (h= ttps://rust-lang-nursery.github.io/rust-cookbook/cli/arguments.html). I= 've used clap recently in a few places and it's very convenient.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.

<= /div>
--0000000000005ea4a605c86db57b--