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

[Tim Marston]

Hi,

On Tue, May 08, 2012 at 10:44:48AM +0200, Lorenzo Bettini wrote:
> On 02/22/2012 09:02 PM, Tim Marston wrote:
> >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

I have submitted a patch for this on savannah, here:
http://savannah.gnu.org/patch/?7778

> >2. Program name [...]

Looking in to this further, I realise that the way that I have changed
the program name with getopt() in the past is to pass a modified argv
array to getopt() where argv[0] points to an alternative name. I know of
no other way to achieve this. And since you can do the same thing with
gengetopt, perhaps we should leave this as it is.

The only exception to this (that I can think of) is when parsing config
files...

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

I tried adding an invalid "foo" option to a config file and got this:

  gtypist: unrecognized option '--foo'

This seems a bit intuitive, for a couple of reasons: Firstly, it is not
mentioned that the error came from a config file (rather than the
command line). Secondly, the option is prefixed with '--' when it was a
plain option name in the config file.

How would you like such errors to appear when they originate from a
config file? I am happy to work on a patch to change this. (We need a
config file in gtypist.) How about this:

  gtypist: unrecognized option 'foo' in .gtypistrc (line 1)

While we're looking at this, I had a question about the program name
that is used to display errors in gengetopt. In some places package_name
is used (this is set to argv[0] in cmdline_parser_internal() before
parsing command-line args). But in other places CMDLINE_PARSER_PACKAGE
is used. Is there a reason for this? And should this be made consistent?

On Fri, May 11, 2012 at 05:10:36PM +0200, Lorenzo Bettini wrote:
> >>>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?
> >
> >Wouldn't you want both? I.e., a way to exclude an option from --full-help
> >*and* a command line option that prevents --full-help from being produced
> >at all? It would be more flexible that way. Or are you concerned about the
> >bloat?
> 
> I'm concerned about the code bloat ;)

OK, what would you have the command-line option be? I just started
working on a patch to add a --no-full-help option, but I realised hidden
options are also available in --detailed-help and what I really want to
do is make hidden options *really* hidden. Can you think of a good
option name for that? The best I can think of is --really-hide.

Looking forwards to hearing from you.

-- 
Tim Marston
ed.am