There is no doubt that a standard command syntax is a "must" for a well-designed system. Certainly, people can learn to use anything, no matter how awkward or confusing it is. However, if people are going to enjoy using the system and if new users are going to be able to pick things up with reasonable speed, the command structure must be consistent, clear, and based on some logical view of human thought processes. The more uniform the syntax is, the less problems a user will have in learning how to use the system and remembering how to use commands.
The need for uniformity is obvious; the definition of uniformity is not so obvious. Thus the following principles have been set down to indicate what we believe constitutes a simple but uniform command syntax.
Keywords for options are always flagged by being marked with a "+" or a "-", or by taking the form "keyword=value[,value]*". Another way of flagging arguments is to surround them in quotes (either single or double). For example, when a command is used as an argument as in EO, the command should be enclosed in single or double quotes. The symbols "<", ">", and ">>" are used to flag files that are used for input, output, and append-output respectively.
Anything else that appears on the command line will be called an "unflagged" argument. The number of unflagged arguments should be kept to a minimum to avoid user confusion. The entities that may normally be unflagged on the command line are
The third point above means that there may be several input arguments listed on the command line, but they should all be the same sort of object. For example, they should all be file names or numbers or expressions. Thus
slist file1 file2 file3
is acceptable but
cmdx filename number
is not.
Note that we allow input arguments to be unflagged but generally recommend that output arguments be flagged with I/O redirection (">" or ">>") or something of the form "output=file". We have decided on this convention because we believe that the command line should reflect the way the user wants to use the command rather than the idiosyncrasies of a particular piece of software. We take the viewpoint that a person wants to use a command to handle a particular set of inputs; for example, he or she wants to list the contents of a given catalog. This may be done by calling a piece of software named "LC" but a human does not intuitively think of things the way "LC" does; the human thought process is essentially
list my catalog
and therefore the command line should be constructed to reflect this.
Modifications to the command line (i.e. the specification of options) are modifications to the basic thought. They may be regarded as afterthoughts or qualifications to the essence of the action the user wants to perform.
Admittedly, thinking of a command as an action operating on inputs is only one approach. For example, one might regard a command as a way to obtain a given output. However, we believe that it is important to have a specific mental set for looking at command syntax and we have chosen the "action-performed-on-input" approach. Designers of new commands should therefore ask themselves "What does the user want to do to a particular object?" rather than "What's the simplest way of writing this program?" It is more important for a system to allow its users to approach commands with a single mental attitude than to save users one or two keystrokes at the expense of consistency.
Keywords with the same name should have the same meaning throughout the system.
Keyword abbreviations should always be well-ordered across commands. For example, if a keyword may be abbreviated to one letter in some commands, it should always be the same letter. If conflicts with other commands force a two-letter abbreviation, it should always be the same two letters. Thus it is acceptable for the same keyword to have a one-letter abbreviation in some commands and a two-letter abbreviation in others; however, the accepted abbreviations must not be different. Furthermore, the accepted one-letter abbreviation must be a subset of the accepted two-letter abbreviation. The same principle applies for abbreviations of more than two letters.
Similar options should have the same name for every command. When a new option is created for a command, the author should not invent a new option keyword if there already exists a suitable keyword serving a comparable purpose in another command. A list of option keywords currently in use is given in "expl syntax keywords".
The meaning of options or arguments should be independent of their position on the command line.
All keyword options should apply to all arguments on the command line.
All commands in a "group" should behave in the same manner. For example, there should be uniformity in all the commands that update random libraries.
The user should always know when a command expects input from the terminal. There are two ways of doing this. The first is to require the user to invoke terminal input with an explicit option on the command line. The second is for the command to warn the user that input is required, usually by issuing some kind of input prompt.
A command should never ignore any input on the command line. If the input contains an unrecognizable option or extraneous data, the command should issue an appropriate error message and terminate.
Exceptions to these principles are only allowed for high-use commands. The reasoning is that special syntaxes may be justified for such commands
Copyright © 1996, Thinkage Ltd.