Provide a way to disable interspersed arguments

[driscoll@…]

I'm trying to write a program that wraps other programs, and allowing switches to come after the first positional argument in this situation is very annoying from the user's standpoint.

If I define the flag --flag in my wrapper, it means that

    my-program target-program --flag

won't run target-program --flag as one would hope, but will treat --flag as an argument to my program.

This means that the user has to run my-program -- target-program --flag every time, which is both annoying and goes against how most such programs work on Unix. (You never see someone say "run sudo -- apt-get install blah." Or xargs, env, nohup, etc.)

As far as I'm concerned, this problem is a showstopper for using the stock Boost po for this sort of program. If the Gflags library didn't have the same limitation, I'd be using it right now instead of having patched Boost. :-)

So I request a setting to disable this sort of interspersed arguments.

---

Fortunately, (one possible) fix seems to be pretty simple from what I can tell. I'll follow up this post with a patch after I get things cleaned back up and such.

[driscoll@…]

Okay, there's the patch, relative to the current svn trunk (rev78961). I didn't put a ton of effort into figuring out the best way to do it, but it seems to work and be relatively elegant. I also had trouble compiling the example program example/options_description.cpp so it's untested as-is, but it does build for me and basically the same patched seemed to work with 1.49.

What I'm not sure about is the best way to add the option to the library instead of hard-coding it. I haven't taken a good enough look to figure out where that should be added. (Maybe the style flags?)

I'm willing to help out a little on this, e.g. writing documentation, if it would help get it into a release. :-)

[Mateusz Loskot]

I asked it on boost-users, but perhaps it's missed. Is this ticket also related this issue #5201 ?

[driscoll@…]

Replying to mloskot:

I asked it on boost-users, but perhaps it's missed. Is this ticket also related this issue #5201 ?

I responded by email (assuming I got the address right) but it occurred to me it might be worth posting back here.

I thank the answer is "no". Though of course I'm not particularly well-versed in the library implementation.

From what I can see, the negative number problem seems to concern when multitoken cuts off its search. I know the code little enough that I'm confused how this happens, but if I use the following option description:

  desc.add_options()
    ("help", "produce help message")
    ("compression", value<string>(), "compression level")
    ("verbose", value<string>()->zero_tokens(), "verbosity level")
    ("email", value<vector<string> >()->multitoken(), "email")
    ;

and run

  ./example --email a b c --compression d

then it gives me a vector of ["a", "b", "c"] for email and a compression of "d". So obviously it's cutting off reading in --email arguments early.

My reading of issue 5201 is that something like --foo 1.0 -1.0 will cause reading of --foo's arguments to end when it sees the next "-".

(Incidentally this example is modified from the one at http://www.boost.org/doc/libs/1_49_0/doc/html/program_options/overview.html#id2500805 which has email as a value<string>. That seems wrong though... are the docs wrong there?)

(However, my analysis here could be wrong.)

My issue is just that when the parser hits the first argument that none of the "style_parsers" recognize, it should stop parsing and treat everything that follows as a positional argument. (This is the same thing that parse_terminator does when it sees a '--' argument on its own, except that the -- gets thrown away. That's why I added the desired behavior at that point in the code.)

[driscoll@…]

Added two possibilities for a patch that allow the user to choose this behavior it via the style parameter of the basic_command_line_parser. The version with allow_interspersed is more consistent with the library now, but breaks backwards compatibility (see ​http://lists.boost.org/boost-users/2012/07/75101.php). The version with disallow_interspersed should not affect current programs.

[driscoll@…]

(Patches include a test case. They are relative to svn trunk @ rev 79301.)

[anonymous]

I'm sad to see that this patch did not make it into 1.52.0.beta1. Is there any chance of seeing it in 1.52.1?