Program Options.. Specifying "-e" as an option value.....
I have an application, which spawns off other applications. As input,
it takes in environment variables and arguments to pass to the resultant
application. For instance:
mutate -E "env_var1=val" -a "." ls
This will run:
ls .
and the environment will only have "env_var1" equal to "val"
So. Something funny comes along when I try to pass "-e" as an argument.
So, in the above would be:
mutate -a "-e" -a "foo" xterm
The program options parser attempts to parse the "-e", and says "I don't
know what it is".
Any thoughts on having it skip that option?
Code Snippits:
po::options_description visible("Program options. Usage %1%");
visible.add_options()
("env,E", po::value
I don't know too much about the library, but see that i your code you
use a capital E. See if there is a way to turn on
case-insensitiveness, or change it to what you want it to be.
Best,
Dee
On Fri, Oct 8, 2010 at 06:19,
I have an application, which spawns off other applications. As input, it takes in environment variables and arguments to pass to the resultant application. For instance:
mutate -E “env_var1=val” -a “.” ls
This will run:
ls .
and the environment will only have “env_var1” equal to “val”
So. Something funny comes along when I try to pass “-e” as an argument.
So, in the above would be:
mutate -a “-e” –a “foo” xterm
The program options parser attempts to parse the “-e”, and says “I don’t know what it is”.
Any thoughts on having it skip that option?
Code Snippits:
po::options_description visible("Program options. Usage %1%");
visible.add_options()
("env,E", po::value
(), "Specify an environment variable to run the executable with. In the form of foo=bar") ("arg,a", po::value
(), "Specify a command line argument to pass to the executable") ;
// Set up some hidden options
po::options_description hidden("Hidden options");
hidden.add_options()
("executable", po::value < std::string>(), "the executable to run")
;
// Set up positional arguments. They are going to be execute
po::positional_options_description pos;
pos.add("executable", 1); // There can only be 1 item executed
// Consolidate all the options into a single one
po::options_description all_options("All Options");
all_options.add(visible);
all_options.add(hidden);
// Parse the command line options
po::store(po::command_line_parser(argc, argv).options(all_options).positional(pos).run(), vm);
po::notify(vm);
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Well. Here's the rub: That's not the requested behavior...
I want behavior, where I specify an argument which follows the following pattern:
-a <some text string>
pseudo-code:
for(int i = 0; i < argc; i++)
{
if argv[i] == "-a"
{
i++;
if(i < argc)
{
arg_vector.push_back(argv[i]);
}
else {} // error
}
}
Instead, it processes each argument individually, attempting to match each argv value with an "argument pattern" (in the style of the following regular expressions which probably don't work, but you should hopefully get the idea: -[a-zA-Z] or --[a-zA-Z]+ )
If they match the regular expression, the are sent to some sort of handler which determines what to do with them. Below is a pseudo-code of how it appears to currently work, and a workaround. I think I just may have hit a special case...
for(int i = 0; i < argc; i++)
{
if isArgument(argv[i])
{
if(handleArgument(argv[i]))
{
// success
continue;
}
/**
// This following case should be added
else if(isEscaped(argv[i]) && argumentHasParameter(argv[i-1]))
{
handleArgumentParameter(argv[i-1], argv[i]);
continue;
}
**/
else
{
// failure
}
}
else if(argumentHasParameter(argv[i-1]))
{
handleArgumentParameter(argv[i-1], argv[i]);
continue;
}
}
I'll be poking around in the code to see what it looks like presently...
-----Original Message-----
From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Diederick C. Niehorster
Sent: Thursday, October 07, 2010 8:17 PM
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] Program Options.. Specifying "-e" as an optionvalue.....
I don't know too much about the library, but see that i your code you
use a capital E. See if there is a way to turn on
case-insensitiveness, or change it to what you want it to be.
Best,
Dee
On Fri, Oct 8, 2010 at 06:19,
I have an application, which spawns off other applications. As input, it takes in environment variables and arguments to pass to the resultant application. For instance:
mutate -E “env_var1=val” -a “.” ls
This will run:
ls .
and the environment will only have “env_var1” equal to “val”
So. Something funny comes along when I try to pass “-e” as an argument.
So, in the above would be:
mutate -a “-e” –a “foo” xterm
The program options parser attempts to parse the “-e”, and says “I don’t know what it is”.
Any thoughts on having it skip that option?
Code Snippits:
po::options_description visible("Program options. Usage %1%");
visible.add_options()
("env,E", po::value
(), "Specify an environment variable to run the executable with. In the form of foo=bar") ("arg,a", po::value
(), "Specify a command line argument to pass to the executable") ;
// Set up some hidden options
po::options_description hidden("Hidden options");
hidden.add_options()
("executable", po::value < std::string>(), "the executable to run")
;
// Set up positional arguments. They are going to be execute
po::positional_options_description pos;
pos.add("executable", 1); // There can only be 1 item executed
// Consolidate all the options into a single one
po::options_description all_options("All Options");
all_options.add(visible);
all_options.add(hidden);
// Parse the command line options
po::store(po::command_line_parser(argc, argv).options(all_options).positional(pos).run(), vm);
po::notify(vm);
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
So, I was poking around in the test cases, and I run across this in cmdline_test.cpp: void test_long_options() { ... test_case test_cases2[] = { {"--bar 10", s_success, "bar:10"}, {"--bar", s_missing_parameter, ""}, ****** // Since --bar accepts a parameter, --foo is // considered a value, even though it looks like // an option. {"--bar --foo", s_success, "bar:--foo"}, ****** {0, 0, 0} }; test_cmdline("foo bar=", style, test_cases2); style = cmdline::style_t( allow_long | long_allow_adjacent | long_allow_next); ... } And further down: void test_short_options() { ... test_case test_cases2[] = { {"-f 13", s_success, "-f:13"}, {"-f -13", s_success, "-f:-13"}, {"-f", s_missing_parameter, ""}, {"-f /foo", s_success, "-f:/foo"}, ****** {"-f -d", s_missing_parameter, ""}, ****** {0, 0, 0} }; test_cmdline(",d ,f=", style, test_cases2); ... } So, it would appear that if both arguments are “long-form” then my problem would go away. But since I’m passing in the short-form arguments (xterm’s –e option has no long-form), I am boned. I think I tried to pass the short-form in as a long form (i.e.: ‘--arg=-e’ and ‘--arg –e’), but I think that these failed as well. Time for some more playing around.........
On Fri, Oct 8, 2010 at 06:19,
I have an application, which spawns off other applications. As input, it takes in environment variables and arguments to pass to the resultant application. For instance:
So. Something funny comes along when I try to pass “-e” as an argument. So, in the above would be: mutate -a “-e” –a “foo” xterm The program options parser attempts to parse the “-e”, and says “I don’t know what it is”.
Oh, I see. The point was that you don't want -e to be parsed, but stored by program_options. Could it be as simple as double quoting it (""-e"") so that only the outer pair of quotes gets stripped by the command line, leaving the inner pair and thus program_options not picking up the option as a command (I hope it actually behaves like that). Alternatively, it seems it might be better that you write your own very simple command option parser that does what you need (e.g. read everything after -a or -E until the other appears), instead of rebuilding significant parts of program_options. Best, Dee
participants (2)
-
david.weber@l-3com.com
-
Diederick C. Niehorster