Re: [help-gengetopt] Groups and other wishes

[Jens Jakobsen]

Hi Lorenzo,

Nice to hear from you too.

Lorenzo Bettini wrote:

Jens Jakobsen wrote:

*** Subsections ***

The idea of subsections is that you can have multiple options which each has suboptions. Consider an animal simulation program, which allow simulation of multiple animals with different characteristica:

animalsimulator --location Madrid --size 10000 --animal cat { -- tale 1 --legs 4 --wings 0} --animal chicken {--tale 0 --legs 2 --wings 2}

you mean that the options in the { } refer to the previous specified --animal, is that right?

Yes, that's korrekt. My main application is network deamons with multiple (unlimited) network interfaces. Each network interface needs parameters such as address, mask, next-hop and dns-servers. It is not an urgent need, but since you are discussing other extensions I thought it would be nice to keep this "wish" in mind.

Of cause in the spirit of GNU subsections should be allowed to be recursive.

Do you mean that { } in command line are standard for getopt?  Sorry about my ignorance but I really didn't know about it.  Could you please provide me with some link to this feature?

I probably made a bad reference. I dont know this option for getopt. For maximum flexibility infinite subsection nesting should be possible. This however is mostly a nice-to-look-at feature, without much practical application. (But then again if the work is the same it might make sense to make nesting possible)

With the introduction of configuration files I sometimes find myself in the situation where a flag is turned
on in the configuration file, but I wish to turn it off again on the command line. This is not possible with the current setup.

*** Flag options ***

you get an error, don't you?

No errors.

Maybe it would be possible to have the flag options followed by an optional on/off argument. In this way it would be possible to explicitly set the option on or off: <--flag> [on|off]. Default behaviour should be the same as it currently is.

I'm not sure I understood this point: it is already possible to specify a flag option with an option on/off argument...

I guess we need some commen terminology here. There is the gengetopt input file (.ggo) and the program configuration file (--conf-parser). I was referring to the program configuration file.

As an example: Typically in my program configuration file I give the flag "fg" meaning that I want the program to run in the foreground for debugging purposes. Command line options normally override options given in the configuration file, but if I specify "--fg" on the command line the program just keeps running in the foreground. I would like to be able to specify "--fg off" on the commandline to explicitly indicate that I want the flag turned off (or --fg on to explicitly turn it on).

I know it is a luxery problem, but I think that the above would be the correct behaviour.

With gengetopt the output filename defaults to */cmdline.h/* and */cmdline.c./*

I find this a little unpractical, and would prefer to have the output filename
default to <input_filename>.h and <input_filename>.c, where the input filename
is given as <input_filename>.ggo. With --file-name it should still be possible
to override the default behaviour.

I'm a little skeptical about this: if one defines the .ggo file with the same name of the program, the default behaviour as you request would then to, silently, override the main file...  I feel safer with the default cmdline.c and cmdline.h :-)

I get your point.

I thought there was some sort of convention for naming of output files: "bison foo.y" generates "foo.tab.c" as output, "m4" writes to standard output, and "flex foo.l" generates "lex.yy.c" as output. So I guess that there is really no convention. Personally I prefer the bison behaviour, but that is just my personal preference, and I have absolutely no problem living with the current behaviour (i just call the input file cmdline.ggo, which gives me the behaviour I desire :-) ).

jens