Reply to: On

[utzoo!decvax!ucbvax!menlo70!sri-unix!tjt at mit-vax]

I agree that all programs should be consistent in the sense two
commands with similar options should in fact have identical options
activated by identical syntax in the command line.  However, there is
clearly a lot of disagreement as to how this should be accomplished.

One example of consistency (or inconsistency) in user commands is
exhibited by expanding "wildcard" file names.  On systems I have used
where individual programs must expand these names (most recently
VMS), (even with operating system or subroutine library help) there
have been programs that do not accept wildcards.  I believe that this
is because on these systems, the user is required to "roll his own"
subroutine (at some level) to handle the wildcards.  While it is true
that VMS does have an extensive subroutine library for dealing with
the command line interpreter, the complexity of this interface is
intimidating.  While this may be an extremely feeble excuse for
deliberately designed utility programs, it ignores the fact that many
useful utilities are not designed, but evolve from `hack' programs,
which become de facto utilities without being reengineered (after
all, they already work, and rule #1 of software maintainence is
"don't fix it if it isn't broken).

On the other hand, expanding all wildcard filenames in the command
interpreter ensures that any program can make use of wildcards,
without additional programming.  However, the wildcard expansion
performed by the shell is context-free (i.e. independent of the
command that the wildcard names are intended for).  The net result is
that while wildcards in the UNIX shell are consistent, they aren't
necessarily what you want (e.g. mv *.c *.c.old).  While "consistency
is not all it's crack up to be", in this case, my preference is for
the simple-minded consistency supplied by the UNIX shell.

The other main area of inconsistency among UNIX commands is
inconsistent syntax for options.  For example, some programs use -l66
to specify 66 lines per page, while others require -l 66, and some
other may require pagesize=66.  Part of this is fundamentally a
management problem rather than a shortcoming of current programming
technology, since programmers are free to choose any names they
please for options.  However, this problem is especially severe when
the programmer has to "roll his own" argument interpreter for each
program, since the simplest programs expose the most inconsistencies
(e.g. requiring single characters options to be specified as separate
arguments such as `ls -l -s -a' as opposed to `ls -lsa').

Implementing a table driven argument interpreter (as in VMS) is one
approach to this problem, although I personally would prefer
`templates' for main programs that interpret various options and
invoke some function on other arguments. If the templates are
properly coded, the action of the program should be easier to
understand than a table driven interpreter. Yes, I realize that one
could always make templates for the tables for the interpreter.
However, the scenario I imagine is similar to using bravo on an alto
starting from some predefined form: the editor would initially
display a skeleton of the program, with the blanks highlighted in
some way (e.g. enclosed in box comments, or underlined, or in a
different typeface or color).

Either of these techniques would make it easier for unix programs to
be consistent.  It is still necessary to decide what we should be
consistent with, and to change the existing utilities.