[boost] Re: Re: Using program_options with other options methods

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-11-24 11:01:54

Hi Jody,

>> Ok, let me start with a caveat: ignoring unknown options can be
>> ambiguous:
>> 
>>    program --something 10 --known_option
>> 
>> Now, is "10" a value of unknown option or positional option? To remove
>> the problems all unknown options must use this form:
>> 
>>    --something=10
>> 
>> which may be problem, or may not, depending on your situation. What do
>> you think?
> 
> 
> I think your example actually brings up several issues.
> 
> First, I was actually a bit surprised to see in the docs that the
> library does not require positional parameters to follow all
> non-positional parameters.  The normal unix use cases typically expect
> options first, then positional parameters.  If the user wants to "end"
> the options early, then a "--" is inserted as an option that
> specifically says to end option processing and begin positional
> processing.
> 
> The ambiguity in your example is actually caused by the interpretation
> of positional options.

It's an explicit decision to allow positional options everywhere. I can't
count the number of times when I run

   cvs ci foo

it failed and I then runned

   cvs ci foo -F /tmp/commit_message_left_by_failed_invocation

to find that options are not allowed after 'foo'.

>> > So, at this stage, I think it requires an interface change to
>> > support this option.
>> 
>> The detail::cmdline constructor actually has 'allow_unregisted'
>> parameter, which is intended to help with this. However, no non-detail
>> interface allows to specify. Frankly, I don't know if I forgot about
>> this or just decided to wait for a user to request this feature
>> explicitly.
>> 
>> Adding a new method to the 'common_command_line_parser' to set
>> 'allow_unregistered' flag and then tweaking
>> common_command_line_parser::run should do the trick? Opinions?
> 
> 
> Maybe.  I am trying to think in terms of bigger picture use case
> support.  I think we need the following...
> 
> 
> 1. Ability to tell the parser to be in "strict" mode or something like
> that, where it assumes options come first, and "positional options"
> follow.  This will remove all ambiguity in parsing options, and AFAIK,
> it is consistent with just about all conventions.

As I mention above, I'm not sure this is right approach.

> 2. Currently, a custom parser can pass two kinds of information; either
> "I do not recognize this option" or "I recognize this option, and here
> is a name/value pair that I want you to use as a substitute for the
> option."  It needs to be enhanced so it can also pass "I recognize this
> option, and you should ignore it."

I agree, and it will be implemented.
 
> 3. Some way for the main cmdline parser to do all its parsing, and
> return all "unrecognized" stuff, without an error.  This way, parsers
> can be chained.  For example, parsing in such a manner...
> program --something 10 --known_option
> would resognize --known_option and I can then as for "parsed" options
> and get a vector of strings representing the parsed options.  I should
> also be able to get a vector of strings of "unparsed" options.

What about 

   program --something 10 11 --known_option

In this case, after parsing know options you'll get 

  --something 10 11

which can be passed to another parser, which will eat 
  
  --something 10

and will leave one token, which will be considered positional options. Seems
OK.

- Volodya