[Top][All Lists]

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

Re: [help-gengetopt] Groups and other wishes

From: Jens Jakobsen
Subject: Re: [help-gengetopt] Groups and other wishes
Date: Wed, 02 Jul 2003 16:32:31 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

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


reply via email to

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