Re: [help-gengetopt] Re: Gengetopt 2.21 enhancement suggestions

[J. David Bryan]

On 16 Oct 2007 at 23:23, Lorenzo Bettini wrote:

> you mean this way you can detect where the error is?

I think so.  "optopt" is set to the unrecognized option character, and 
"optind" is set to the next argv index (so "optind - 1" should index to the 
unrecognized option).  If I need more detailed error coverage, I can leave 
"opterr" = 1.

In my specific application (that prompted the suggestion), I have to parse 
the command line myself, as the syntax of one of the options cannot be 
handled by gengetopt.  But instead of programming everything myself,  I'd 
like gengetopt to handle everything except that special option.  In this 
case, the "error" from the parser simply means that it has found the option 
that I must parse from argv myself.  I don't want to print an error 
message, because there is no error.  :-)


> well, actually, when I was thinking about enums I was thinking about
> ALSO storing values as enums....

In the original suggestion from last year, it was proposed to generate 
enums instead of strings.  For backward compatibility, you thought that 
keeping both representations was best.  I agree.

But I have proposed generating enums _or_ strings (or ints, floats, etc.), 
depending on the user's choice.  Backward compatibility is guaranteed if 
the user chooses strings (or chooses the default, which should be strings). 
 If the user chooses enums, then enums should be all that are needed.  If 
the user needs strings, he can choose strings.

So:

  option "rotate" r "Rotate clockwise" values="0","90","180","270"

...would be the same as:

  option "rotate" r "Rotate clockwise" string values="0","90","180","270"

...and would generate strings.  And:

  option "rotate" r "Rotate clockwise" enum values="0","90","180","270"

...would generate enums.  No need to generate strings too, I think, because 
I have explicitly said that I want enums.

                                      -- Dave