Joerg Schilling wrote:
> The Sun tooochest has a big value and it has a big future potential.
> Don't ever think about giving it up, but _we_ (the OpenSolaris community)
> need to find a way to overhoul it.
>
I think we all agree this is good. The devil lies in the details about
how to best make this
happen.
BTW: I think the short term gains made by OpenSolaris will be in
userland (and device
support), simply because we've not spent enough resources on it and the
learning curve
on the kernel (and to be honest, kernel politics - IMHO) is rather
steep. (Its not that the
politics will exclude anyone, its just that the politics *and* the code
have steep learning
curves.)
> - SCCS has been converted by Sun to use getopt() and getopt() is
> not a high quality finction. It is far way from being able to
> correctly replace hand written option parsers. Similar deficits are in
> GNU getopt_long().
>
> As a result, admin(1) has been broken and did (as a result of another
> bug) not allow an "empty MR list" at all (although documented). After
> fixing this bug, it does still suffer from the fact that
>
> getopt(argc, argv, "m:");
>
> does not allow "-m" as -m with no arg but only -m "".
>
If I read this right, what you are suggesting is adding a bug.
getopts is quite explicit that optional option arguments are not allowed.
There is good reason for this. Consider the synopsis:
foo [ -m [option-arg-for-m] ] file ...
Now, take the example:
foo -m foo bar
Is foo the option argument for -m or one of the file operands? Its
ambiguous. GNU's command line
definitions allow this and commands are left to heiristically resolve
the ambiguity. We don't go there.
There is even a lengthy discussion around the CLIP standard as to why
this is. We do not desire
ambiguous command lines.
> Such problems could be solved with my getargs() which implements
> a richer set of formats and allows e.g. to enforce a space
> between the option and the parameter or to enforce no space.
>
As it so happens, I'm probably the guy to historically talk to about
getopts.
However, I'm not sure that we want a richer set of formats. We want
something that forces the caller (as
much as possible) to the getopts standard we adhear to which is a slight
extension to that from the
SUS standards.
Of course, behind all this is the fact that there are just about as many
command line format preferences
as there are programmers in the world, perhaps more. Couple that with a
dirth of actual research and
this become a ripe area for bar room discussions. Some old but real
research (customer polls) done
by Kathy Hemmingway when she was at AT&T yielded an overwhelming answer:
"We really don't care what it (the standard) is, but we want one and
we want it to be consisantly
applied".
We try to follow this dictum. That's why strict getopt conformance is
strongly encouraged.
- jek3
