Handling "actions" with program_options
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 <jmmv84@gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/
As I saw elsewhere today, I'm new here. On Sun, 20 Feb 2005 22:02:38 +0100, Julio M. Merino Vidal <jmmv84@gmail.com> 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<std::string, std::string> 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
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
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 <jmmv84@gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/
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
participants (3)
-
Julio M. Merino Vidal -
The Grumpiest Man You Know -
Vladimir Prus