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