program_options positional and required arguments
More usability issues with program_options: I couldn't really find
much mention of positional options in the docs. I'm writing a typical
command line program: one that takes some set of optional options and
a single required positional argument. Currently, I'm doing (where
namespace po = boost::program_options):
po::options_description desc("Allowed options");
desc.add_options()
("help,h", "show this help message")
...
("exe", po::wvalue
Yang Zhang wrote:
More usability issues with program_options: I couldn't really find much mention of positional options in the docs. I'm writing a typical command line program: one that takes some set of optional options and a single required positional argument. Currently, I'm doing (where namespace po = boost::program_options):
po::options_description desc("Allowed options"); desc.add_options() ("help,h", "show this help message") ... ("exe", po::wvalue
(), "the command line to execute"); po::positional_options_description posopts; posopts.add("exe", -1);
po::variables_map vm; po::store(po::wcommand_line_parser(argc, argv). options(desc).positional(posopts).run(), vm); po::notify(vm); if (vm.count("help") > 0) { cout << desc << endl; return 0; } ... if (vm.count("exe") == 0) { cerr << desc << endl; return 1; } wstring exe(vm["exe"].as
()[0]); I had to add the exe option to the regular (non-positional) options_description as a vector<wstring>, causing it to show up as an option in the usage message.
You can create a hidden options group and put 'exe' there.
Omitting it resulted in errors about the option being unregistered (even after trying to add allow_unregistered). Why would I get this error?
Because you say that all positional options should become values of the 'exe' option -- that you did not define.
Shouldn't the wcommand_line_parser::run method be doing this checking after it has collected all the sets of option descriptions? Can I get rid of this? What's the proper way to express what I want?
Is there a way to require the positional argument occur (1) at least once and
No. There are patches in the works to implement 'required' options, though.
(2) at most once (besides manual checks after parsing)?
psoptions.add("exe", 1) ? - Volodya
On Sun, Nov 8, 2009 at 11:56 PM, Vladimir Prus
Yang Zhang wrote:
I had to add the exe option to the regular (non-positional) options_description as a vector<wstring>, causing it to show up as an option in the usage message.
You can create a hidden options group and put 'exe' there.
Omitting it resulted in errors about the option being unregistered (even after trying to add allow_unregistered). Why would I get this error?
Because you say that all positional options should become values of the 'exe' option -- that you did not define.
But I *do* define it, in the positional_options_description.... If you look at the code, notice that "exe" has to be defined twice, in two different description objects.
Shouldn't the wcommand_line_parser::run method be doing this checking after it has collected all the sets of option descriptions? Can I get rid of this? What's the proper way to express what I want?
I guess these questions still stand. And the only suggested change to do things "properly" is to make "exe" hidden? Besides, can't a user still perform --exe blah, even if it's hidden from the usage message? -- Yang Zhang http://www.mit.edu/~y_z/
Yang Zhang wrote:
On Sun, Nov 8, 2009 at 11:56 PM, Vladimir Prus
wrote: Yang Zhang wrote:
I had to add the exe option to the regular (non-positional) options_description as a vector<wstring>, causing it to show up as an option in the usage message.
You can create a hidden options group and put 'exe' there.
Omitting it resulted in errors about the option being unregistered (even after trying to add allow_unregistered). Why would I get this error?
Because you say that all positional options should become values of the 'exe' option -- that you did not define.
But I *do* define it, in the positional_options_description....
Well, that does not count as definition -- positional_options_description is merely a thin map into real options.
If you look at the code, notice that "exe" has to be defined twice, in two different description objects.
Yes, indeed, that's because the options_description is the *primary* description, and describes types and other things. positional description only relays to the primary description, and is generally unable to specify anything about the option.
Shouldn't the wcommand_line_parser::run method be doing this checking after it has collected all the sets of option descriptions?
I don't understand this question.
Can I get rid of this? What's the proper way to express what I want?
I guess these questions still stand. And the only suggested change to do things "properly" is to make "exe" hidden? Besides, can't a user still perform --exe blah, even if it's hidden from the usage message?
Yes. Is it that much of a problem? - Volodya
participants (2)
-
Vladimir Prus
-
Yang Zhang