Hi!

I did some further investigating, and found out that our current
getopt implementation is not SUSv2-compliant.

To wit:
If an executable calls getopt with an option string containing '-',
and is subsequently called with
	program -
NetBSD's current getopt implementation returns '-'. According to SUSv2
(XSH5 in particular), getopt should stop parsing and return -1 in the
following cases:
  o argv[optind] is NULL (mentioned only for completeness)
  o *argv[optind] is not '-' (the character)
  o argv[optind] is the string "-"
  o argv[optind] is the string "--"

su(1) for example uses the current (wrong) behaviour in a
standards-defying way by just putting '-' in the option string. This
must be handled manually instead.

So, to be more standards compliant, we have to break binary
compatibility (that is, do the __RENAME dance).

From my point of view, there aren't any reasons that "-" should still
be allowed in option strings: You could only validly return '-' as an
option if you find it inside a string of concattenated short options
like "program -abcd-".

We could still allow '-' as the first character in an option string to
be compatible to GNU getopt, which interprets that to return
non-option arguments as option arguments to the option '\01', that is
	program -a file -b
returns 'a', '\01' with optarg "file", and 'b'.

Since GNU libc's getopt_long allows this use of '-' as the first char
in the option string, getopt_long tries to be reasonably compatible to
GNU getopt_long (after all, there's no standard for getopt_long), and
I'd like to use share the internal code of getopt and getopt_long, I
think it would be a good idea to introduce the same behavior into
getopt.

There's one other special character in GNU getopt's handling of the
option string: '+' as first character. That specifies that the
arguments of the program should _not_ be reordered, i.e.
	program -a file -b
will not be handled as
	program -a -b file
cf. my last mails on the subject. Since this is and will be default
behaviour in NetBSD's getopt, we should probably just ignore it (that
is, not recognize it as option '+'). It's not really a problem,
though: if we don't special case it, such programs will just accept
'-+' and then not know what to do with it -- but it's the user's fault
in the first place, since he should know better than to call them with
'-+' ;-)

I've also thought about consistency a lot, and my opinion now is that
getopt_long shouldn't reorder by default, either (in contrast to GNU's
getopt and getopt_long do) because that's the most consistent way with
NetBSD getopt.

If we really mean it, we should also remove all uses of GNU
getopt{,1}.{c,h} files in src/gnu/ -- otherwise there will be some
special programs that _do_ reorder their arguments.

Thanks for reading so far.

Bye,
 Thomas

P.S.: Please CC.

-- 
Thomas Klausner - wiz@danbala.tuwien.ac.at
A man may be very industrious, and yet not spend his time well. There is no
more fatal blunderer than he who consumes the greater part of life getting
his living. -- Henry David Thoreau


-- 
Thomas Klausner - wiz@danbala.tuwien.ac.at
A man may be very industrious, and yet not spend his time well. There is no
more fatal blunderer than he who consumes the greater part of life getting
his living. -- Henry David Thoreau