i found out that you can reinitialize getopt by setting optind = 0. i tried it and it worked. the thing is i didn't see it documented on the man pages or the info pages. did i miss something, or is this just something that's "well-known but undocumented".

Hi,

optind, AFAIK is an internal counter telling getopt where to find it's next operand. That is, argv + optind is where it'll find it's next argument. So, resetting it will obviously make it look at arguments it has previously seen. It's probably not documented as it's not to be meddled with and not many situations demand this kind of a behaviour.

Setting it to 0 might not be such a good idea, as argv + optind = argv. So, argv[0] will be accessed and that is the program name. But, depending on when optind is internally incremented, you might find that even though you set it to 0, it might be incremented to 1.

Arvind

PS: I just checked the glibc implementation of getopt. optind is checked to see if it's 0. If it is, it's set to 1, and getopt is re-initialized. Nothing special.

PS: Have you tried setting it to a negative number?

there's also a static variable nextchar (as mentioned in the man page) that's involved. for example, if you used a command of the form "command -abc", getopt would have optind = 1 while it parses all three options, and nextchar would be incremented as the options are retrieved. but, apparently, setting optind = 0 resets everything, including nextchar. that's good. but, i like to have everything documented in the man page; i don't like to discover things by tinkering with them.

Well, it's not meant to be known at all. You're given an interface to work with and that interface is documented. But, if you change an internal variable and something happens, then, you can hardly complain that it's undocumented behaviour. :-)

If this was in C++ or something, it'd be a private variable and you couldn't access it anyway. But, the abstraction facilities offered by C are not great. So, you can tinker with the internal variables of getopt. If such behaviour was wanted by many, then, a function called "_getopt_initialize" (as in the sources) would've been documented.

optind is meant purely for finding out which is the next non-option argument, and to use the rest of them.

Arvind

yes, one would think. but, then -- and this is the reason i was asking -- when one looks at some of the GNU source code, one sees things like:

the above is from env.c in coreutils.

see what i mean?

Yes, I suppose they set a bad example. As they're all GNU code, they know how each one will be implemented and so, they make use of that fact to (maybe) make it work a little faster. But, I'm sure you'll agree that it's not a very good idea to be so dependant on implementation. What happens if the getopt implementation changes?

For the record, the getopt file says, about optind:

Later, it says:
Arvind

yes, i agree with you that an undocumented feature shouldn't be used.
by the way, what you quoted had more information than was contained in the man pages. where did you find it?

I found it in the glibc sources of getopt. Do you want me to send it to you? It's a small file, getopt.c.

There's a slightly modified version of getopt.c here: http://mia.ece.uic.edu/cgi-bin/lxr/h...v=poptop-1.1.4

Line numbers 130 to around 145 are what you're looking for.

Arvind

arvind, thank you very much. no need to send it to me, though. i'm walking away from this with the conclusion that this feature is undocumented (unless one reads the source code itself -- because even the comments to the code leave room for speculation).