Using getopt to parse multi-argument options

[Daniel R. Levy]

In article <1989Jan19.192946.15825 at utzoo.uucp>, henry at utzoo.uucp (Henry Spencer) writes:
< In article <3141 at ttrdc.UUCP> levy at ttrdc.UUCP (Daniel R. Levy) writes:
< >Actually, what Roy had in mind IS possible.  Yes it violates the syntax
< >standard, but if one is masochistic enough to WANT that, it's doable through
< >suitable abuse of optind...
< 
< This is not portable; it assumes a specific implementation of getopt.
< 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?
I mean, why else should we care what optind is prior to at least one usage
of getopt?

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:

	...
	int i;
	...
	while (...getopt...) {
	...
	case 'x':
		... /* validate the presence of two numeric arguments */ ...
		xmin=atof(optarg);
		xmax=atof(argv[optind]);
		argv++;
		argc--;
		break;
		...
	}

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? :-)
-- 
Daniel R. Levy             UNIX(R) mail:  att!ttbcad!levy
AT&T Bell Laboratories
5555 West Touhy Avenue     Any opinions expressed in the message above are
Skokie, Illinois  60077    mine, and not necessarily AT&T's.