Re: Output of --help and --version

On 02/22/2012 09:02 PM, Tim Marston wrote:
> Hi,
>
> 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.

well, probably version_text would be better

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

Fortunately, when I introduced the structure cmdline_parser_params I had 
compatibility in mind :) you won't break compatibility, since, if you 
add another field in the structure, all you have to do is to generate 
cmdline_parser_params_init accordingly so to initialize to a default 
value that field, see the currently generated version

void cmdline_parser_params_init(struct cmdline_parser_params *params)
{
   if (params)
     {
       params->override = 0;
       params->initialize = 1;
       params->check_required = 1;
       params->check_ambiguity = 0;
       params->print_errors = 1;
     }
}

so you won't have problems if you add another field in the struct :)

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

config file handling may be probably bugged at the moment I guess... and 
I don't know how to implement the feature you talk about... any idea?

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

probably a way of customizing the program name could be good

>
> 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?
>

gengetopt starts to have many command line arguments, and probably many 
keywords...  I guess it's hard to have a way to make all users happy: 
anyone will want to have a complete control on the generated code, but, 
being C, I think it's hard to achieve it... probably another command 
line option would be preferable?

Again:

For the moment, I cannot add any new feature to gengetopt myself: it's 
such a busy moment that I really can't work on it... especially if it 
requires to write C code (as opposite to C++ code), as in the case of 
the runtime wrapping...

Of course, if you can provide patches (and unit test cases) I'll be 
happy to collaborate

cheers
	Lorenzo

-- 
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
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