[Top][All Lists]

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

[help-gengetopt] Output of --help and --version

From: Tim Marston
Subject: [help-gengetopt] Output of --help and --version
Date: Wed, 22 Feb 2012 20:02:18 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16


A couple of ideas regarding --help and --version output...

1. Extra text after --version.

A lot of GNU programs output extra text (in addition to the version
string) when passed --version. Commonly, this includes a copyright
message, an email address to report bugs to and a website address for
the software. Gengetopt doesn't provide a way to specify this at the moment.

One solution might be to add an additional directive to the .ggo file
that allows the developer to specify text to appear after the version
string. For example, in the form:

  version_text "a textual sentence"

Another option might be to hijack the existing "text" directive and use
it to specify version text when it is used prior to a "purpose",
"description" or an "option" directive.

2. Program name

There is currently no facility to specify the program name, as output by
gengetopt (or getopt). Getopt offers this facility, but gengetopt
doesn't pass it on to the developer.

This could be implemented by adding another parameter to the
cmdline_parser_params struct for the desired program name which, if
NULL, defaults to argv[0]. The downside to this is that it would
silently break compatibility. Programs that instantiated the struct, but
did not fill in the new element, would leave the element uninitialised.

Although I have to confess that I haven't actually looked at gengetopt's
behaviour in regard to errors in config files (as opposed to the command
line), it seems to me that this might be a useful facility there as
well. I can imagine a developer wanting to choose how error messages are
generated when those errors occur in a config file.

A bigger question here is whether this facility *should* be offered, or
whether forcing the use of argv[0] as the program name is a more
desirable option.

3. There is currently no way to *really* hide an option (so that it
isn't even listed in --full-help).

Two ways to implement such a feature spring to mind: a new command-line
argument could be added to gengetopt that prevents it from adding
--full-help entirely, or options could be tagged with a new keyword,
like "really_hidden" that prevents them being a candidate for inclusion
in the --full-help output. In fact, both these things could be added.

But is the current design intentional? Would this facility be
undesirable on the grounds that it would make the software less
transparent to the user?

Tim Marston

reply via email to

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