1 Aug
2021
1 Aug
'21
10:51 p.m.
Am Sat, 31 Jul 2021 11:56:51 -0400
schrieb Paul Winalski <paul.winalski(a)gmail.com>:
On 7/31/21, Michael Siegel <msi(a)malbolge.net>
wrote:
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.
--
Michael
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.