1003.2: command name changes

[Donn Terry]

>From: kingdon at ai.mit.edu (Jim Kingdon)
>
>    My recommendation for years has been that vendor additions be confined
>    to upper case, leaving lower case options for the (gradually growing)
>    standard environment.
>
>But this way every time an option gets standardized, all
>implementations and users have to change.  This does not accord with
>"minimal changes to existing practice".  Long options (e.g. "ls +all
>+format long" (or "ls +all +fo l" if those abbreviations are
>unambigous) instead of "ls -al"), however, are less likely to conflict
>with each other, so this is the way to go particularly for options
>not used interactively or options rarely used.

If there is a reserved namespace for vendors, then they can freely
add symbols in that namespace.  If/when a feature becomes standardized,
it is standardized into the namespace reserved for the standard.  As long
as the vendor has sense enough to accept the old flag as a synonym (at
least for a while) nothing breaks.   The breaks occur when the vendor
didn't use the reserved namespace (possibly because there was none)
and the standard usurps that symbol for something else.  (Probably because
some other vendor had used it for something else which was valuable.  The
usual compromise here is to use a new letter (with no mnemonic value!)
that no-one is using.)

Again, one man's existing practice is another's gratuitous change.

Donn Terry (again, speaking only for myself)

Volume-Number: Volume 18, Number 49