Subject: Re: the state of getopt(3)
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 10/02/2004 15:37:41
[ On Friday, October 1, 2004 at 15:15:38 (-0700), Greywolf wrote: ]
> Subject: Re: the state of regex(3)
> I am still not amused by getopt()'s behaviour under Linux.
> One could argue that 'cc' was another funky one, seeing as one could
> cc -o target source0.c source1.c ... sourceN.c -llib0 -llib1 ...
If I remember correctly the "cc" usage was one of the few major examples
used in the argument in favour of mixed options and parameters
(i.e. against what we now call the POSIX getopt() rules).
The argument against holding up "cc" as an example was that most, if not
all, at the time, implementations of it refused to allow spaces between
option flags and their optarg values. Maybe that's still the case, but
the prevalence of GCC everywhere skews the perception.
My opinion on the mixed options debate has probably flip-flopped a half
a dozen times over the years.... I really like having a consistent and
predictable syntax, and I really hate having to deal with exceptions to
the rules too.
The problem is that a jammed-together interface like that of "cc" just
cannot be made to conform to all the rules no matter what they are! We
could probably get the toolchain to conform to the existing POSIX rules
if we went back to invoking all the compiler passes separately I
And then there are the other classic examples of "dd" and "find". ;-)
(and "sort", but POSIX 'fixed' that one... :-)
Greg A. Woods
<email@example.com> +1 416 489-5852 x122 http://www.planix.com/