Re: flag setting issues with override

Papp Gyozo (VBuster) wrote:
> Hi there, 
> 
>> The detailed scenario is that config file is parsed first and then the
>> command line. The latter has precedence over the former, that is, command
>> line arguments overrides option values given in config file. In my
>> understanding "override" should mean "confirm" in case of flags at least
>> when different settings are originated from different sources (or different
>> runs of gengetopt_internal()).
> 

Hi there

I answer this email together with the first one.

Yes, as you said, I don't like flag options ;) that's something I had 
already found in gengetopt when I started to maintain it.  Actually, I 
don't know the real semantics myself, and I guess the same flag should 
not be given twice on the command line (which includes also 
configuration files).

But I understand your issue, but I cannot change the current behavior in 
order not to break backward compatibility.  I'll go back to this in a 
minute.

First, out of curiosity, why are you using flag options instead of 
options without arguments?  Would you be able to simulate the same 
behavior of flag options?  This is just my curiosity, in order to be 
able to understand whether we're able to get rid off flag options someday :)

> In short term, I'm thinking of introducing a new parameter for the parser to check if flag is set more than once. This way we could preserve the original behaviour and support the new one as I suggested yesterday.
> 
>>     struct getoptions_params    ggo = {
>>                                     1, // override what is in cmdline struct
>>                                     1, // initialize struct w/ default
>> values
>>                                     0, // check required
>>                                     0, // check ambiguity
> 
> check ambiguity would be fine but I avoid to overload with additional functionality.
> The new one could be named as check flag or something like that to refer this problem.
> 

This is the best solution, since adding a new parameter is backward 
compatible, so how about override_flags?  If set to 0, this would 
simulate your

if (field_given && *field_given && ( !override || arg_type == ARG_FLAG ))

i.e.,

if (field_given && *field_given && ( !override || (arg_type == ARG_FLAG 
&& !override_flag)))

what do you think?

> In a long run, I would prefer to change flag option generation as to gcc's options.
> I mean to generate to separate options for setting and reseting flags:
>   -flag    # to enable (switch on) the `flag'
>   -no-flag # to disable (switch off) the `flag'
> 

I was asked to add such functionality and I'd like to work on this, but 
these would not be real flag options: it would be options without name 
with an automatic generation of the '-no-' corresponding version

> I hope this way we could avoid several problems and misunderstandings around flag options. Unfortunately it breaks compatibility.
>

why would it break backward compatibility?  I mean the solution with 
additional param should not break backward compatibility (if set by 
default to 1).

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