[program_options] is a more complicated usage supported?
Hi there, I'm using program_options on 1.36, quite successfully so far with only simple use cases. However, now I have to do something a little more tricky. Essentially, I'd like to parse everything before a certain point and treat everything after that as positional_options. Goal is to have a variable command line that can take arbitary commands, much in the fashion tools such as valgrind and strace would. Consider this: ./mytool --myopt 1 --anotheropt bla ./someapp --appoption 1 So mytool would need to parse it's own options 'myopt' and 'anotheropt' and then be aware of the string './someapp --appoption 1' to eventually fork whatever is there. And to make it a little more interesting some of the options should be optional. Alas, docs don't really get into that so I'm wondering if/how this could be done. This is what I got: po::options_description desc("Allowed options, after that state the desired command"); desc.add_options() ("anotheropt,a", po::valuestd::string(), "some other option") ("myopt,o", po::valueboost::uint16_t()->default_value(1), "optional value 1") ; po::variables_map vmap; po::store(po::parse_command_line(argc, argv, desc), vmap); po::notify(vmap); // at this point I got my options. po::positional_options_description pd; pd.add("command", -1); po::parsed_options parsed = po::command_line_parser(argc, argv).options(desc).allow_unregistered().run(); std::vectorstd::string command_options = collect_unrecognized(parsed.options, po::include_positional); // here I got command_options filled with the unrecognized options. ...snip... That works OK as long as my command line does not have any options starting with - or -- at it's own. As soon as the command to be forked has such options, the first po::store() would throw because it tries to parse them. Is there any way to prevent this? Thanks and greetings... Stephan
participants (1)
-
Stephan Menzel