Using getopt to parse multi-argument options

[Henry Spencer]

In article <3146 at ttrdc.UUCP> levy at ttrdc.UUCP (Daniel R. Levy) writes:
>< Unless things have changed, the getopt(3) documentation makes no promise
>< that user changes to optind will be reflected back into getopt's innards.
>
>Literally taken, you are quite right.  I am reading between the lines of
>the man page and making an educated guess.  Can you suggest a reason for
>the statement "Because optind is external, it is normally initialized to
>zero automatically before the first call to getopt," other than the
>implication that optind's value will influence the behavior of getopt?

There is a clear implication here that the initial value matters.  There
is no similar statement about subsequent values.  If one wants portable
software, one is not allowed to make educated guesses about the software;
one is entitled to trust only properties that are explicitly documented.

>But, supposing we take your objection at face value, that we can't count on
>user changes in optind being reflected into the internal workings of getopt.
>O.K., how about mucking with argv and argc instead of with optind...
>The documentation doesn't say that we must give each call to getopt() the same
>argc and the same argv does it now?  Huh? Huh? :-)

No, it doesn't.  It's also kind of vague on what might happen.  I fear it
comes under the same heading:  "behavior not documented, may vary between
implementations".
-- 
Allegedly heard aboard Mir: "A |     Henry Spencer at U of Toronto Zoology
toast to comrade Van Allen!!"  | uunet!attcan!utzoo!henry henry at zoo.toronto.edu