Handling "actions" with program_options

newer
RE: [Boost-users] [serialization]...

Julio M. Merino Vidal

20 Feb 2005 20 Feb '05

9:02 p.m.

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). 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... Thanks, -- Julio M. Merino Vidal http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

Show replies by date

The Grumpiest Man You Know

20 Feb 20 Feb

10:34 p.m.

As I saw elsewhere today, I'm new here. On Sun, 20 Feb 2005 22:02:38 +0100, Julio M. Merino Vidal wrote:

...

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.

I have a call: desc.add_options() ("help,h", "Blab to the users") That seems to allow --help and contractions, because of the "help, and -h, because of the ,h". It seemed to me that it's "<long option name>,<short option letter>"

...

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).

I was looking for something similar. I defined: struct my_parser { my_parser() : found_subcmd(false) {}; std::pair operator() (const std::string & s) { found_subcmd = found_subcmd || (s[0] != '-'); if (found_subcmd) { return make_pair(std::string("sub-cmd"), s); } else { return make_pair(std::string(), std::string()); } }; void reset() { found_subcmd = false; }; private: bool found_subcmd; }; Then used it as the external parser. po::store(po::command_line_parser(argc, argv).options(desc) .extra_parser(cnos_cmd_parser()).positional(p).run(), vm); This puts the pre magic word stuff in vm.

...

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:

I'd guess that you'd create another variable map and run a different parser on the words in the vector sub-cmd. But bear in mind the first line. ;) ---- Blue skies

Vladimir Prus

24 Feb 24 Feb

7:45 a.m.

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

Julio M. Merino Vidal

4:39 p.m.

On Thu, 2005-02-24 at 10:45 +0300, Vladimir Prus wrote:

...

Hi Julio,

...
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.

Somewhat yes. But anyway, I'm not using options in different places with different meanings ;)

...

...
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?

I tried, but I couldn't decipher the documentation. IMVHO, it lacks some info about what "positional options" are, their purpose, and how they are intended to be used. However, if that's the way to go, I'll look at it again. Thanks, -- Julio M. Merino Vidal http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

Vladimir Prus

28 Feb 28 Feb

9:04 a.m.

Julio M. Merino Vidal wrote:

...

...
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.

Somewhat yes. But anyway, I'm not using options in different places with different meanings ;)

Then, why does it matter where the option is specified ;-)

...

...
...
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?

I tried, but I couldn't decipher the documentation. IMVHO, it lacks some info about what "positional options" are, their purpose, and how they are intended to be used.

You mean that http://www.meta-comm.com/engineering/resources/cs-win32_metacomm/doc/html/pr... is not sufficiently detailed? I'll try to improve that section, then. - Volodya

7212

Age (days ago)

7220

Last active (days ago)

List overview

Download

4 comments

3 participants

participants (3)

Julio M. Merino Vidal
The Grumpiest Man You Know
Vladimir Prus