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 _______________________________________________ Help-gengetopt mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-gengetopt
