help-gengetopt
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [help-gengetopt] Gengetopt 2.21 enhancement suggestions


From: Lorenzo Bettini
Subject: Re: [help-gengetopt] Gengetopt 2.21 enhancement suggestions
Date: Mon, 15 Oct 2007 14:49:59 +0200
User-agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828)

J. David Bryan wrote:
Greetings,


hi there

sorry for the delay of my answer but I had a busy week and I also need to move to Turin (http://tronprog.blogspot.com/2007/10/researcher-in-turin.html well it's a little bit off topic but I wanted to share this with you :-)

I have been using gengetopt for a few months and have used it to generate option processors for about ten programs. From my use, I have three suggestions for a future version:

 1. Allow the automatic addition of the help and version options if the
    user respecifies the short options (but not the long options).

    Currently, if either the long or short option is respecified, the
    built-in usage is suppressed.  For example, if the user specifies
    his own "-h" ("--height") option, the built-in help option is lost,
    and the user must provide it manually.  However, often we still want
    to use "--help" for the help option and "--version" for the version
    option (just without short options).  It would be nicer if gengetopt
    provided these automatically.  Of course, if the user specified a
    "--help" or "--version" (long) option explicitly, then gengetopt
    should not provide its own.

    The attached "gengetopt-2.21-enh-1.diff" suggests an implementation.


yes, you're right!


 2. Provide a way to suppress the error message from "getopt_long" for an
    invalid option.

    The "--no-handle-error" option to gengetopt causes the parser to
    return an error value to the calling program.  The manual says that
    this is so "the program can print a help message."  However,
    "getopt_long" always prints an error message before returning the
    error indication.  This is because "opterr = 1" is set within the
    parser and cannot be changed by the user.

    It would be nice if the value (0 or 1) could be specified by the
    user, so that the user program can handle the error completely if
    desired.  Either "opterr" could be set automatically to 0 if the
    "--no-handle-error" option to gengetopt was used, or "opterr" could
    be set from a new cmdline_parser_params" item that the user would
    set explicitly (with default to 1) and then pass to
    "cmdline_parser_ext".

    This is useful in cases where options are used that either do not
    match C identifier syntax (e.g., "-?") or are unknown until run time
    (e.g., "-<n>", where the values for <n> are determined by the
    contents of a file specified on the command line).  The generated
    parser can still be used to handle the help and version options (and
    perhaps more), while the caller can handle the "unparseable" options
    without spurious error messages appearing.

    The attached "gengetopt-2.21-enh-2.diff" suggests an implementation.


OK, but, in case, how can someone understand if there's actually an error and print the corresponding error message?

by the way, the print_errors field should default to '1' to be backward compliant


 3. Allow an option with a "values=" restriction to return a specified
    argtype.

    When "values=" is specified, the manual says that "The type is
    considered string and must not be specified."  However, the option
    value often is not a string and must be converted for use.  For
    example, a "--rotate" option might limit values to 0, 90, 180, or
    270 degrees.  The rotation value is an integer, but it will be
    returned as a string, and the caller must do string comparisons or a
    string-to-int conversion.

    What would be more flexible would be to allow "argtype" to be
    specified in addition to "values=".  So if we had:

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

    ...then the return value would be one of the four integers converted
    from a string.  Specifying "string" as the "argtype" would return a
    string value (as gengetopt does now).  Specifying "enum" would
    generate an enumeration type (example: "enum rotate_type { rotate_0,
    rotate_90, ... };") and return one of the enumeration values.  Note
    that if the argtype defaulted to "string," the new behavior would be
    backward-compatible.

    This issue was previously discussed in:

    http://lists.gnu.org/archive/html/help-gengetopt/2006-04/msg00007.html

    ...in the context of returning enumeration values (only).


yes I remember that and should have worked on that already; do you think using enum values would solve also the argtype issue? I'm asking because adding enum values would be quite simple, while adding types to values would require some more time (it could be done anyway)

thanks for the patches!

as I said previously I'm still working on the re-engineering of the generated code (which now should be much more manageable and thus also adding new features would be easier), but I'm almost done, so I hope I could start working on new features soon.

look forward to hearing from you!

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]