[Boost-users] Re: Handling "actions" with program_options

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-02-24 02:45:58

Hi Julio,

> Hi everybody,
> 
> I'm working on  a program whose its actual syntax is:
> 
> vcsme [-c conf_file] [-q] action [action_args]
> 
> (very similar to the CVS one).
> 
> I'm trying to convert it to use boost::program_options (to get rid of
> the getopt(3) call, and to have long options), but I don't know how to
> do it.
> 
> So far, I've added the code to handle -c and -q options.  This was
> very easy to do, given the examples on the web.  The only annoyance is
> that the options are accepted everywhere, but I'd prefer to only accept
> them if they come before the action name (because the action itself
> might allow options).

FWIW, I find this CVS like behaviour (where options mean different things
depending on where you use them), to be highly confusing and undesirable.
If one option mean the same everywhere, it means the interface much
simpler.

> Unfortunately, I'm stuck with the latest part, the one to handle
> actions.  There must always be an action passed to the program, which
> may optionally accept arguments.  Some example invocations:
> 
> vcsme -q update
> vcsme update gtk+ glib NetBSD
> 
> But I can't see any way to do this with program_options.  Using getopt,
> I do:
> 
> argc -= optind; argv += optind;
> 
> after processing the options, so that argv[0] becomes the name of the
> action, and any remaining entries are its arguments.  The same can be
> achieved with getopt_long.
> 
> So... is it there any way to do what I want with the actual
> implementation?  Can't see anything relevant in the docs...

Did you try using positional options to parse the 'action' and arguments to
it?

- Volodya