From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-09 01:22:41
Pavol Droba wrote:
> On Mon, Jun 09, 2003 at 09:08:37AM +0400, Vladimir Prus wrote:
>> Hi Pavol,
>> > I have a request regarding config file support in the program option
>> > library. Currently when the parser encounters an unknown option in the
>> > config file, parsing is stopped with an exception.
>> > Together with fixed option definition, this feature disables a
>> > possibility to have an arbitrary options in the config file, whose
>> > exact format is not know prior to parsing.
>> > An example:
>> > I'd like to have something like this in the config file
>> > <conf-file>
>> > [module]
>> > file-count = 3
>> > file-name1 = 001.aaa
>> > file-name2 = 002.aaa
>> > file-name3 = 003.aaa
>> > </conf-file>
>> > where the number of file-name* lines is not know before parsing, and it
>> > is up to user to specify as many as she wants, or the format and number
>> > of options is dependant on some other option ( i.e. file-count )
>> > I think, that it would be nice to be able to force the parser to accept
>> > also the options not described in the option_descriptions and have a
>> > way to work with them.
>> In fact, there's a (undocumented) feature which applies to your case:
>> ("file-name*", ....)
>> After this, every option starting with "file-name" will be accepted. Is
>> this appropriate for your use case?
>> - Volodya
> Well, it looks fine, but still, there can be other cases which could not
> be coverd by a simple wildcard like this.
> I think, it would still be benefitial if there would be possibility to
> parse options which have not been described.
Thinking a bit more, I note that cmdline class has a feature to allow
unregistered option, while config_file does not. For uniformity alone,
it will be good to add such feature to config_file. Noted, thanks!