override among command line and config file options

[Papp Gyozo (VBuster)]

Hi there,

I have another problem with no proper solution up to now.

The basic logic of my app is the following:

1) parse commandline (getoptions_ext)
2) try to locate a config file (depends on command line options)
3) parse configfile with no override and no initialize to the same cmdline structure
4) check required fields

We stated in the docs for a while that commandline options take precedence over config file. It causes me a little problem at least with group options (these are the old mutual exclusive options, Lorenzo ;)

If an option from a group is given in commandline and in the config file, the generatad parser returns an error:

"vbscan: 2 options of group ... were given. At most one is required. in configuration file vbscan.ini" (*)

Of course, if I allow override during config file parsing, this error won't raise. However config file options should not override any previously set options.

I think what I came to my mind so far would not be not so popular.

i) move all (or almost all) checking to a dedicated function like require and call this function at the very end of parsing when nothing modifies the option structure. Well actually it may cause compatibility breaks in many applications. However I think it would be great anyway apart from the current situation.

ii) use two different option structure one for commandline and an other for configfile, and then merge manually or

iii) by tweaking the current logic:
  - parse commandline into temporary struct to get out the name of the configfile
  - parse config file into final struct
  - parse again commandline into final struct with override(!)

Do you know a better approach to circumvent this situation?



(*) there is a small typo in the error message string. The closing dot is before the %s format argument. It should be:

      fprintf (stderr, "%s: %d options of group ... were given. At most one is required%s.\n", argv[0], ... ));




--
Papp, Gyozo
Virusbuster Kft


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

> Hi there,
>
> I have another problem with no proper solution up to now.
>
> The basic logic of my app is the following:
>
> 1) parse commandline (getoptions_ext)
> 2) try to locate a config file (depends on command line options)
> 3) parse configfile with no override and no initialize to the same cmdline
> structure
> 4) check required fields
>
> We stated in the docs for a while that commandline options take precedence
> over config file. It causes me a little problem at least with group options
> (these are the old mutual exclusive options, Lorenzo ;)
>
> If an option from a group is given in commandline and in the config file,
> the generatad parser returns an error:
>
> "vbscan: 2 options of group ... were given. At most one is required. in
> configuration file vbscan.ini" (*)

Again ... forgot to say that the most annoying situation when the very same option is given in both command line and config file. Reporting an error in such cases looks a little bit weird for me.


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Tim Post-3]

On Mon, 2008-04-07 at 16:17 +0200, Papp Gyozo (VBuster) wrote:

> i) move all (or almost all) checking to a dedicated function like require
> and call this function at the very end of parsing when nothing modifies
> the option structure.

> iii) by tweaking the current logic:
>   - parse commandline into temporary struct to get out the name of the configfile
>   - parse config file into final struct
>   - parse again commandline into final struct with override(!)

> Do you know a better approach to circumvent this situation?

I like option iii. I already implement option i to a degree, such as
checking that paths, ports, interfaces, files (etc, ...) aren't bogus
prior to starting. Even though all arguments in a group might be
satisfied, some may be mistakes. By checking that, I'm more or less
already doing what is described in option i.

I would think that most people do something similar?

Cheers,
--Tim

--
Monkey + Typewriter = Echoreply ( http://echoreply.us )



_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Tim Post-3]

On Mon, 2008-04-07 at 16:49 +0200, Papp Gyozo (VBuster) wrote:

> Again ... forgot to say that the most annoying situation when the very
> same option is given in both command line and config file. Reporting an
> error in such cases looks a little bit weird for me.

Same here, which is why I like the idea of the temporary struct for
argv[], even though we really only need the config file option from it
initially. Its useful to hold this struct for issuing warnings.

If tmp->option and final->option are present and not the same, a warning
could be issued saying "Warning, command line option (option) takes
precedence over configuration directive (option)"

In most cases the user would know that, since command line options are
supposed to override configuration directives .. but its still handy and
(imho) more 'proper' to be noisy about it.

I'd actually be all for a toggle that stops freeing of the temporary
structure so that its up to us to free it once we're done with it.

So, really, the temporary structure would serve two useful purposes.

Cheers,
--Tim

--
Monkey + Typewriter = Echoreply ( http://echoreply.us )



_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Papp Gyozo (VBuster) wrote:

> Hi there,
>
> I have another problem with no proper solution up to now.
>
> The basic logic of my app is the following:
>
> 1) parse commandline (getoptions_ext)
> 2) try to locate a config file (depends on command line options)
> 3) parse configfile with no override and no initialize to the same cmdline structure
> 4) check required fields
>
> We stated in the docs for a while that commandline options take precedence over config file. It causes me a little problem at least with group options (these are the old mutual exclusive options, Lorenzo ;)
>
> If an option from a group is given in commandline and in the config file, the generatad parser returns an error:
>
> "vbscan: 2 options of group ... were given. At most one is required. in configuration file vbscan.ini" (*)
>
> Of course, if I allow override during config file parsing, this error won't raise. However config file options should not override any previously set options.
>
> I think what I came to my mind so far would not be not so popular.
>
> i) move all (or almost all) checking to a dedicated function like require and call this function at the very end of parsing when nothing modifies the option structure. Well actually it may cause compatibility breaks in many applications. However I think it would be great anyway apart from the current situation.
>
> ii) use two different option structure one for commandline and an other for configfile, and then merge manually or
>
> iii) by tweaking the current logic:
>   - parse commandline into temporary struct to get out the name of the configfile
>   - parse config file into final struct
>   - parse again commandline into final struct with override(!)
>
> Do you know a better approach to circumvent this situation?
>
>
>
> (*) there is a small typo in the error message string. The closing dot is before the %s format argument. It should be:
>
>       fprintf (stderr, "%s: %d options of group ... were given. At most one is required%s.\n", argv[0], ... ));
>
>
>
>

Hi there

sorry for my silence but it was a busy week :-)

are you suggesting something to be implemented in the generated code or
proposing some programming idioms?  I just want to be sure I understand
correctly...

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



_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

Hi there,

> Papp Gyozo (VBuster) wrote:
> > The basic logic of my app is the following:
> >
> > 1) parse commandline (getoptions_ext)
> > 2) try to locate a config file (depends on command line options)
> > 3) parse configfile with no override and no initialize to the same cmdline
> structure
> > 4) check required fields
> >
> > We stated in the docs for a while that commandline options take precedence
> over config file. It causes me a little problem at least with group options
> (these are the old mutual exclusive options, Lorenzo ;)
> >
> > If an option from a group is given in commandline and in the config file,
> the generatad parser returns an error:
> >
> > "vbscan: 2 options of group ... were given. At most one is required. in
> configuration file vbscan.ini" (*)
> >
> > I think what I came to my mind so far would not be not so popular.
> >
> > i) move all (or almost all) checking to a dedicated function like require
> and call this function at the very end of parsing when nothing modifies the
> option structure. Well actually it may cause compatibility breaks in many
> applications. However I think it would be great anyway apart from the
> current situation.

> are you suggesting something to be implemented in the generated code or
> proposing some programming idioms?  I just want to be sure I understand
> correctly...

If we prefer i) then I think something has to be done.

In my understanding we have a fairly neat interfaces to collect options from different sources: command line, config file. Moreover mode is supported for partioning options, we can add more than one parser to the same program etc. So method for inputs are OK.

However there is no dedicated function to check only multiple options, groups, dependencies, modes etc in a smooth way so there is no easy way to partition and customize your validation process. The only thing you can check separately is require.

So what I proposed was to move as many "inter-option" validation routines as possible to a separate interface function which could be called at certain points in the application. I mean "inter-option" that it validates the relationship between two or more option: group, dependencies, modes just to name a few. (I think per option checks, like type, argument needed and its type and so on, may remain where it is now.) Actually multiplicity is a little bit tricky because if the application deals with multiple sources an option can occur more than once in every sources.

These above were just vague ideas and wonderings. The original problem can be "worked around"


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Tim Post-3]

If a command line option over-rides a config file directive, for sanity
sake, its good to know.

Storing argument directives and config file directives in separate
structures easily permits custom sanity checks. If used, its up to us to
free the temporary structure, which is OK :) The worst case is it only
leaks once.

ACK on this, it would really be helpful.

Cheers,
--Tim

On Mon, 2008-04-21 at 11:38 +0200, Papp Gyozo (VBuster) wrote:

> Hi there,
>
> > Papp Gyozo (VBuster) wrote:
> > > The basic logic of my app is the following:
> > >
> > > 1) parse commandline (getoptions_ext)
> > > 2) try to locate a config file (depends on command line options)
> > > 3) parse configfile with no override and no initialize to the same cmdline
> > structure
> > > 4) check required fields
> > >
> > > We stated in the docs for a while that commandline options take precedence
> > over config file. It causes me a little problem at least with group options
> > (these are the old mutual exclusive options, Lorenzo ;)
> > >
> > > If an option from a group is given in commandline and in the config file,
> > the generatad parser returns an error:
> > >
> > > "vbscan: 2 options of group ... were given. At most one is required. in
> > configuration file vbscan.ini" (*)
> > >
> > > I think what I came to my mind so far would not be not so popular.
> > >
> > > i) move all (or almost all) checking to a dedicated function like require
> > and call this function at the very end of parsing when nothing modifies the
> > option structure. Well actually it may cause compatibility breaks in many
> > applications. However I think it would be great anyway apart from the
> > current situation.
>
> > are you suggesting something to be implemented in the generated code or
> > proposing some programming idioms?  I just want to be sure I understand
> > correctly...
>
> If we prefer i) then I think something has to be done.
>
> In my understanding we have a fairly neat interfaces to collect options from different sources: command line, config file. Moreover mode is supported for partioning options, we can add more than one parser to the same program etc. So method for inputs are OK.
>
> However there is no dedicated function to check only multiple options, groups, dependencies, modes etc in a smooth way so there is no easy way to partition and customize your validation process. The only thing you can check separately is require.
>
> So what I proposed was to move as many "inter-option" validation routines as possible to a separate interface function which could be called at certain points in the application. I mean "inter-option" that it validates the relationship between two or more option: group, dependencies, modes just to name a few. (I think per option checks, like type, argument needed and its type and so on, may remain where it is now.) Actually multiplicity is a little bit tricky because if the application deals with multiple sources an option can occur more than once in every sources.
>
> These above were just vague ideas and wonderings. The original problem can be "worked around"
>
>
> _______________________________________________
> Help-gengetopt mailing list
> Help-gengetopt@...
> http://lists.gnu.org/mailman/listinfo/help-gengetopt

--
Monkey + Typewriter = Echoreply ( http://echoreply.us )



_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Papp Gyozo (VBuster) wrote:

> Hi there,
>
>> Papp Gyozo (VBuster) wrote:
>>> The basic logic of my app is the following:
>>>
>>> 1) parse commandline (getoptions_ext)
>>> 2) try to locate a config file (depends on command line options)
>>> 3) parse configfile with no override and no initialize to the same cmdline
>> structure
>>> 4) check required fields
>>>
>>> We stated in the docs for a while that commandline options take precedence
>> over config file. It causes me a little problem at least with group options
>> (these are the old mutual exclusive options, Lorenzo ;)
>>> If an option from a group is given in commandline and in the config file,
>> the generatad parser returns an error:
>>> "vbscan: 2 options of group ... were given. At most one is required. in
>> configuration file vbscan.ini" (*)
>>> I think what I came to my mind so far would not be not so popular.
>>>
>>> i) move all (or almost all) checking to a dedicated function like require
>> and call this function at the very end of parsing when nothing modifies the
>> option structure. Well actually it may cause compatibility breaks in many
>> applications. However I think it would be great anyway apart from the
>> current situation.
>
>> are you suggesting something to be implemented in the generated code or
>> proposing some programming idioms?  I just want to be sure I understand
>> correctly...
>
> If we prefer i) then I think something has to be done.
>
> In my understanding we have a fairly neat interfaces to collect options from different sources: command line, config file. Moreover mode is supported for partioning options, we can add more than one parser to the same program etc. So method for inputs are OK.
>
> However there is no dedicated function to check only multiple options, groups, dependencies, modes etc in a smooth way so there is no easy way to partition and customize your validation process. The only thing you can check separately is require.
>
> So what I proposed was to move as many "inter-option" validation routines as possible to a separate interface function which could be called at certain points in the application. I mean "inter-option" that it validates the relationship between two or more option: group, dependencies, modes just to name a few. (I think per option checks, like type, argument needed and its type and so on, may remain where it is now.) Actually multiplicity is a little bit tricky because if the application deals with multiple sources an option can occur more than once in every sources.
>
> These above were just vague ideas and wonderings. The original problem can be "worked around"
>

so you suggest to have another function for this, just like the
check_required function that can be called from the program, right?

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



_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

> > So what I proposed was to move as many "inter-option" validation routines
> as possible to a separate interface function which could be called at
> certain points in the application. I mean "inter-option" that it validates
> the relationship between two or more option: group, dependencies, modes just
> to name a few. (I think per option checks, like type, argument needed and
> its type and so on, may remain where it is now.) Actually multiplicity is a
> little bit tricky because if the application deals with multiple sources an
> option can occur more than once in every sources.

> so you suggest to have another function for this, just like the
> check_required function that can be called from the program, right?

Yeah, something like that.


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt