Path: utzoo!mnetor!uunet!husc6!yale!cmcl2!brl-adm!umd5!ames!ucbcad!ucbvax!SEAS.UCLA.EDU!bilbo.geoff
From: bilbo.geoff@SEAS.UCLA.EDU (Geoff Kuenning)
Newsgroups: comp.windows.x
Subject: Re: A couple of comments on the Intrinsics document
Message-ID: <8801080451.AA05990@ATHENA.MIT.EDU>
Date: 8 Jan 88 03:25:38 GMT
References: <8801071936.AA15919@gilroy.dec.com>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 60

The command-line parsing is, as I said, "ill-conceived, nonstandard,
and incompatible."  In support of my statements:

(1) The easiest charge to support is "nonstandard".  Check out getopt(3)
    if you have System V or 4.3, or the Posix document.  There is an
    explicit and adopted standard for Unix command line processing.
    It specifies that (a) switches may be only a single character,
    (b) switches may be introduced ONLY by the "-" character, and (c)
    arguments may be either concatenated or separate from their
    switches.  The existing toolkit code violates all three of these
    specifications.

    Many people have argued that single-character switches have
    significant drawbacks, so that it is necessary to ignore the standard.
    In general, these people are disregarding the fact the decision was
    made after careful consideration of these drawbacks and of the
    impact on the existing Unix community of changing the standard.
    When one chooses to ignore the decision of the Posix committee, one
    is in effect saying that one knows more about Unix and the Unix
    community than they do.  Before doing this, I'd think about checking
    the membership of the committee and seeing if I really think I
    know more than them.  Doug Gwyn, just to name one member, is hardly
    a schmuck.

(2) The existing command-line processing is incompatible with existing
    Unix, existing standards, and existing software.  I already discussed
    the standards issue (getopt) above.  As to existing Unix, note that
    the *only* standard Unix command that takes multi-character dash-separated
    switches is "find", which is universally cited as an example of
    "strange" command-line switches.  ("dd" also takes multi-character
    switches, and is even stranger).

    Existing software expects single-character switches, usually processed with
    getopt.  A conversion to X-Windows (e.g., gnumacs) requires the porter to
    either throw out the existing getopt-based code and use the toolkit code,
    convert the toolkit to use getopt, or work with a godawful conglomeration.

(3) The existing toolkit argument processing is ill-conceived for a whole bunch
    of reasons.  First, it is a nonstandard reinvention of the wheel that
    forces any toolkit user to violate existing standards.  Second, it
    forces all toolkit users to accept so-called "standard" interpretations
    of certain switch strings (even though the standard exists only within the
    toolkit).  Third, the switch variations currently supported (SepArg, IsArg,
    etc.) contain too many options (one lesson of comparing VMS with Unix
    is "don't give the user options!") that are of limited usefulness
    and encourage still more nonstandard code (notablyIsArg).  Fifth,
    it requires toolkit porters to re-implement the OS-specific command-line
    processing, even though the OS already provides a perfectly usable
    command-line routine such as getopt.  Sixth, it splits command-line
    parsing into more than one place, making maintenance and debugging that
    much more difficult.

In summary, *please* don't force this idea on us.  Provide it as an option
if you really want to encourage to X community to violate existing standards
and write software that the government won't buy.  But kindly provide a
way around this silly code for those of us who understand why it's better
to stick with a flawed standard than to go off in a new direction all
our own.

	Geoff Kuenning	geoff@lcc.ucla.edu	geoff@ITcorp.com