[help-gengetopt] Gengetopt 2.21 enhancement suggestions

[J. David Bryan]

Greetings,

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.


 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.


 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).

                                      -- Dave

gengetopt-2.21-enh-1.diff
Description: Binary data

gengetopt-2.21-enh-2.diff
Description: Binary data