Boost logo

Boost :

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

- Volodya

Boost list run by bdawes at, gregod at, cpdaniel at, john at