[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [help-gengetopt] flag setting issues with override
From: |
Lorenzo Bettini |
Subject: |
Re: [help-gengetopt] flag setting issues with override |
Date: |
Sun, 07 Feb 2010 14:30:04 +0100 |
User-agent: |
Thunderbird 2.0.0.23 (X11/20090817) |
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