[help-gengetopt] Eliding ellipsis and passing unhandled options to caller

[Jason Sewall]

I have only just started investigating gengetopt as an alternative to
manually using getopt_long --- so far, seems nice to me --- and I have
a few questions/comments.

The unamed-opts option is quite useful, but it always appends an
ellipsis (...) to the end of its argument in the usage string:

i.e., with --unamed-opts=FILE

Usage: program [OPTIONS]... [FILE]...

If FILE is intended to be singular, this usage string might be
confusing. Obviously I can just set a custom usage, but that has a
slight annoyance of not being able to refer to other define values,
like PROGRAM[_NAME]. Is there some way the user can telegraph if there
is to be exactly 1 unnamed option or more, and skip adding ... if it
is singular? Perhaps --unamed-opt=FILE?

I was also curious about unhandled named options. At least once in the
past, I have used getopt_long with opterr = 0 and used the '?' return
value to pass all unrecognized options to the calling program. The use
case here was that there was some unlimited set of key/value pairs
that the user might want to set on the command line, and getopt would
just ignore them, letting later handlers deal with them.

It seems like gengetopt doesn't allow this. It's not even clear to me
what --no-handle-error does, since it seems to still print out an
error message  (I believe getopt_long is actually doing it) in the
presence of an unrecognized option.

See here for a snippet of how I used this:
http://pastebin.com/sZXihbPS

The *ARRAY* macros are just some tools for growing an array. The ideas
is that candidate_kvs is handled by some other application-specific
routine later one.

I'm curious to hear what you think.

Cheers,
Jason