Re: [help-gengetopt] override among command line and config file options

[Tim Post]

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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-gengetopt
-- 
Monkey + Typewriter = Echoreply ( http://echoreply.us )