name=value or -n value?

[Laws at SRI-AI.ARPA]

From:  Ken Laws <Laws at SRI-AI.ARPA>

I have grown used to "-" introducing options, although it does play
havoc with programs that can take negative numbers or negated strings
as arguments (e.g., grep looking for "-1").  In my own parsing routines
I have kept the "-" convention, and have provided routines for checking
the number of terms following a flag (i.e., before the next flag) so
that the programmer can provide defaults or can print an error message
if the wrong number of arguments are given.  This is integrated with
my package for parsing ordinary (nonflag) command-line arguments.
The programmer-specified defaulting options can be rather complex, as
in: use the command-line argument if given and legal; if given and
illegal, use an interactive query to offer the default; if not given,
use the default [with or] without asking the user, unless no default
was specified in which case query the user with no default.  All this
is wrapped in a fairly simple C subroutine call interface that lets the
programmer specify the query string, criteria for legal parameters,
and optional help messages for illegal input and for user queries.

One thing that is missing in Unix syntax is the notion of nested arguments,
as in Lisp.  Strings provide the ability to group terms into a single
argument, but there is no other mechanism for passing down a list
(e.g., a coordinate pair) as a single parameter that the program can
parse later.  Such capabilities are needed for "intelligent" interfaces
that are able to recognize different ways of specifying an entity
from the form of the specification.  We'll just have to live with using
different flags to introduce different syntactic forms of an argument.
(Example: I use "-f 10 10 -n 15 15", and "-w 10 10 25 25" as two ways
of specifying a 15 x 15 screen window extending from (10,10) to
(25,25).  With an argument grouping capability one could specify
something like "((10 10) + (15 15))" or "((10 10) to (25 25))", or
"(pointA to pointB)", or "windowA", or whatever other syntax the program
was prepared to accept.  This can be done now with string arguments,
but only if the programmer is willing to write a fairly hairy ad hoc
parser.)

I have also come to prefer spaces to commas as argument separators, and would
recommend that the csh {a,b}.c notation be converted to use spaces.  There
needs to be a way to denote missing arguments, however, as well as a way
to test for them in programs.  I use "?", "??", and related entities
to trigger default values, prompting, help facilities, etc.  Unfortunately
the quotes are necessary to get these symbols past the shell syntax
expansion.  Perhaps "@" or a lone "-" could be used to stand for a missing
argument.

					-- Ken Laws
-------