I've been googling this morning trying to find more information about getopt usage and I haven't found anything I didn't really already know. I'm looking to see if getopt supports two features.


1) An option that may or may not be followed by an argument
For example, `-h` by itself prints out the basic help/usage message, but `-h c` prints detailed information about the `-c` argument. I've found no such way to do this with getopt


2) An option can be followed by any number of arguments
For example, let's say I want to turn on debug printing with the `-d` option. `-d all` would turn on debugging print messages for the entire program. `-d audio video` would turn on debugging for just the audio and video sections. Etc. But it seems that getopt only supports a single argument per option...?



Am I just toally missing something here? Does getopt really lack the functionality to do these two things? I can't for the life of me find anything that either confirms or denies the existance of the two said features. Any gurus hanging around?

I'm not a getopt guru, but it seems like for #2 you could just change how you pass it on the command line, for instance either:

-d "audio video" (So that "audio video" is seen as one command-line argument)

or

-d audio -d video (so that the -d option is found twice...)


I'm not quite sure how getopt would know where to stop otherwise for multiple parameters. Say for instance you have a program that takes in a filename to work on as the last parameter:

./someprogram -d blah filename.blah
./someprogram -d blah1 blah2 filename.blah

How would you tell getopt that in the second case you want the blah1 and blah2, but in the first case you just want the one? It doesn't feasible to me without getopt knowing intimate details about the usage of your program....

Good point there, I didn't think about that one. Well, if getopt assumed that every argument that begins with '-' is a command, then all it should have to do is peak at the next option to see whether the first character is a dash or not. But yeah, if the program takes an input filename or whatever that doesn't have an argument indicator then it would be ambiguos and wouldn't work. But you could always make the input file follow a -i argument to get around that...

Part of the reason for having getopt() as a standard library function is to make command line options for most all utilities on your system behave the same way. Because of this, I think your users would prefer you not get tricky with them : )

Your first requirement has similar problems with ambiguity as the second; that's probably why getopt doesn't let you do it. For that, you might just take the non-option arguments as the argument to -h. I assume that -h is unlikely to be used with other options and arguments anyway.

For the second problem, -d foo -d bar is what I'd expect to see, though -d "foo bar" is reasonable too. You could support both as long as your debug sections don't have spaces in them.