Am I the only one that doesn't like the --something-or-other options
One of the ARC cases that I am working on publishing to the community
relates to Command Line standards:
PSARC 1999/645: CLIP (Command Line Interface Paradigm)
One of the key discussions revolved around "when it was appropriate" to
add long options to a command. This is a summary of that discussion.
We have a notion of a "collection of related commands" that are expected
to have similar, predictable behavior. When you add a new command to that
collection, it needs to fit in. "When in Rome, do as the Romans do."
This also applies to making modifications to a collection. If one were
to, say, add long options to /bin/ls, and not to the rest of the POSIX
collection, we would expect to see an influx of support calls requesting
that the rest of the system support long options. "You can't be a little
bit pregnant."
When we discussed adding long options to the stuff in /bin/, we were faced
with having to do a lot of relatively straightforward work on a lot of
commands for very little "business payoff" and with some undefined risk.
What kinds of risk? By definition, existing scripts and customers don't use
the long options, so this would be justified only by how it enabled new
markets (i.e., porting from Linux...); adding long options diverges the
commands from the POSIX spec, so there might be issues there; following
some other spec for the names of the long options (gnu?) means that we
would have two disjoint sources of potential change to manage - what if
POSIX changes and what if GNU changes.
We didn't reject such types of change, but rather we questioned the need
and priority for going back and retrofitting existing commands and came to
the conclusion that there were other, more important things to focus on
at that time. [This may change with OpenSolaris, so please don't take it
as a definitive comment on today's discussion!] The advice we gave was:
Retrofitting legacy utilities to the CLIP specification is a
significant management decision. There are significant costs
and marginal associated benefit. There would be nothing
wrong with chartering projects to extend appropriately
defined sets (as discussed in [1]) of utilities, but it is
very likely that there are better ways to direct those
resources. In particular, the committee sees little motiva-
tion to extend the core UNIX utilities maintained by the ON
Consolidation.
The unchartered conversion of legacy utilities to the CLIP
specification by engineers should also be discouraged. It
is almost assured that a few such projects will be presented
with the rationale that it was done on the engineer's own
time. Accepting such projects is likely to lead to incon-
sistent expectations on commands even though consistency is
understood to be the primary desire of our customers. After
a few such integrations, we can expect customer RFEs (possi-
bly submitted as bugs) requesting that utilities in other
areas of the system be converted.
____
1. CLIP Specification (not included here)
-John Plocher
blogs.sun.com/plocher
_______________________________________________
opensolaris-discuss mailing list
[email protected]
