[TUHS] Systematic approach to command-line interfaces

Michael Siegel msi at malbolge.net
Mon Aug 2 02:51:37 AEST 2021

Am Sat, 31 Jul 2021 11:56:51 -0400
schrieb Paul Winalski <paul.winalski at gmail.com>:

> On 7/31/21, Michael Siegel <msi at malbolge.net> wrote:
> >
> > 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.  
> 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.

Being able to provide interactive help is exactly what the person who
suggested grammar-based parsing to me was working on. I hadn't even
thought about that at first. But given my recent investigation into
built-in command documentation on Unix-like systems, I tend to think
this would be a great enhancement – if it was implemented with a
strict focus on not getting in the way, i.e., the user should be able
to switch it off completely, and search-as-you-type would be opt-in, if
provided at all.


More information about the TUHS mailing list