[boost] [Program Options] terminate parsing after first positional argument

Subject: [boost] [Program Options] terminate parsing after first positional argument
From: Evan Driscoll (driscoll_at_[hidden])
Date: 2012-10-24 20:03:08

This summer there was some discussion on the boost-users list about
whether it is possible to use program_options to write an interface like
'xargs' (or time, or env, or nohup, or ssh, or sudo, or valgrind, or
Python, or lots of other tools) where any options (--foo) that appear
after the first positional arguments are considered positional arguments.

In other words,'xargs foo --help' in real Unix behaves the same as
'xargs -- foo --help', rather than 'xargs --help foo', but you can't get
this behavior currently from Boost.

I proposed a couple patches, and there was a very small amount of
discussion, but it sort of petered out (in part because I went away for
a couple weeks at an inopportune time). Is there any interest in
adopting them? The bug I filed just got another hit from someone else
who wants it.

 https://svn.boost.org/trac/boost/ticket/6991

The following is a summary of the status:

The ideal would be to have an 'allow_interspersed' style option which
would be set by default (to give the now-usual behavior of "cmd arg
--opt" being the same as "cmd --opt arg") but which a client program
could unset if they wanted the xargs-like behavior.

However, I don't see how to do this, because
> If someone says
>    style_t style = allow_short | allow_slash_for_short
> I can't automatically go and set allow_interspersed for them as well.

And so without some ugly and not-worth-it coding tricks (changing
style_t to a class), unless I'm missing something you can't pick this
ideal without breaking backwards compatibility.

So I instead suggested a new 'disallow_interspersed' style option, which
would be off by default (keeping backwards compatibility) but you could
set it to get xargs-like behavior, but this is inconsistent with all the
other style flags which are allow_xxx.

So what do you want to do regarding this issue?

References:
  Trac issue: https://svn.boost.org/trac/boost/ticket/6991
     (includes a patch for both of those options)

  The previous messages in this discussion, on boost-users:
     http://lists.boost.org/boost-users/2012/07/75100.php

Evan