J. David Bryan wrote:
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. :-)
OK :-)
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.
However, 90 would not be a valid enum (since it starts with a number) so
enum values should still be generated in some modified way, e.g.,
enum_90 or ENUM_90, that was my main problem...
however, I'll work on this
cheers
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DSI, Univ. di Firenze
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
_______________________________________________
Help-gengetopt mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-gengetopt
