Re: [help-gengetopt] Ambiguity elimination by using both command line options and configuration file

[Yegor Yefremov]

Lorenzo Bettini schrieb:
> Yegor Yefremov wrote:
> > Lorenzo Bettini wrote:
> > > Yegor Yefremov wrote:
> > >  
> > > > Dear list,
> > > >
> > > > I have following situation:
> > > > I have both command line parameters and configuration file and I want
> > > > prevent defining the same option in both command line and 
> > > > configuration
> > > > file. At first I parse the command line options to obtain the 
> > > > configfile
> > > > file name and then I parse the configfile. When I define the option in
> > > > both I don't get any error. The program can check if I defined two
> > > > options in the same command line but it can't check it if I defined 
> > > > them
> > > > both in command line and configuration file due to the fact, that only
> > > > local_args_info will be checked. I think it is important issue to 
> > > > reduce
> > > > debugging overhead when operating with both command line and
> > > > configuration file.
> > > >     
> > >
> > > Hi there
> > >
> > > as you proposed in a previous private email, one solution could be to
> > > add a command line option
> > >
> > > -C|--conf-parser-noambiguity
> > >
> > > in order to make the parser check for these ambiguities...
> > >
> > > another solution might be to use different args_info structures for
> > > parsing the configuration file and the command line and use a function
> > > generated by gengetopt, e.g., check_dup (similar to the check_required
> > > generated function) that checks that non multiple options are not
> > > specified in both structures, what do you think?
> > >
> > > This would avoid overwhelming the parser function with many 
> > > parameters...
> > >
> > > or did you mean that, when --conf-parser-noambiguity is specified and
> > > override is 0 when passed to the parser function, then a duplicate 
> > > would
> > > generate an error?  Did you mean that --conf-parser-noambiguity should
> > > be a command line option or a gengetopt's command line option?
> > >
> > > cheers
> > >     Lorenzo
> > >
> > >   
> > Hi Lorenzo
> >
> > my suggestion about --conf-parser-noambiguity was for gengetopt's 
> > command line option as --conf-parser itself. I think it will be 
> > easier to implement as to define another structure. Here the example 
> > how to check the occurrence of the option:
> >
> >        else if (strcmp (long_options[option_index].name, "cycles") == 0)
> >          {
> >            if (local_args_info.cycles_given || 
> > (args_info.cycles_given && !override)) // additional check
> >              {
> >                fprintf (stderr, "%s: `--cycles' option given more 
> > than once%s\n", argv[0], (additional_error ? additional_error : ""));
> >                goto failure;
> >              }
> >
> > I think it would do the job.
>
> Hi there
>
> I prefered to add a struct for holding additional parameters to parser 
> functions.
>
> This struct also has the parameter check_ambiguity that does what you 
> need (see the documentation, and the test_conf_parser_ov4.c test file).
>
> I've uploaded a beta version here
>
> http://rap.dsi.unifi.it/~bettini/gengetopt-2.21b.tar.gz
>
> by the way, this version also generates doxygen comments (for the 
> moment only in the header file); please let me know whether these 
> comments look fine
>
> hope to hear from you soon
>
> cheers
>     Lorenzo
Hi Lorenzo,

ambiguity check works great! Thanks a lot!

About comments:
1. AFAIK, when you describe structure members, it is not necessary to 
add  @brief. It will be shown in the brief list anyway
2. By functions one could add @brief so that this text appears in the 
brief list

Besides this everything is perfect. I'm looking forward for the official 
2.21!

cheers
   Yegor