When implicit value is specified, command line specified value is ignored #211
Comments
|
See #210 |
mstemm
added a commit
to falcosecurity/falco
that referenced
this issue
Feb 4, 2022
Fill in an initial falco::app::cmdline_options class using cxxopts library to hold options: - falco::app::cmdline_options contains a cxxopts::Options object to parse options and a cxxopts::ParseResult to hold the result. - The only meaningful public method is parse() which parses argc/argv and returns true/false + error. - The parsed options are all public instance variables of the object and generally use the same names of the corresponding variables in the old falco_init(). These variables are all bound to the corresponding command line option and are updated in parse(). - In a few cases, the command line option does not directly map to a bound variable (e.g. -b to set buffer format, -p/-pk/-pc to set extra formatting options, etc.) In these cases the option values are read after parsing and update the public instance variable. One public-visible change is that --list, which used to support an optional argument, has been broken into two options. --list now always displays all fields, and a new option --list-source displays fields for a specific source. This is because the cxxopts library has a bug (jarro2783/cxxopts#104, jarro2783/cxxopts#211) that does not parse implicit options correctly when specified as "--list <source>". --list=<source> or --list<source> would work, but I wanted to support space separated options and I expect use of --list with a source was uncommon. Signed-off-by: Mark Stemm <[email protected]>
mstemm
added a commit
to falcosecurity/falco
that referenced
this issue
Feb 7, 2022
Fill in an initial falco::app::cmdline_options class using cxxopts library to hold options: - falco::app::cmdline_options contains a cxxopts::Options object to parse options and a cxxopts::ParseResult to hold the result. - The only meaningful public method is parse() which parses argc/argv and returns true/false + error. - The parsed options are all public instance variables of the object and generally use the same names of the corresponding variables in the old falco_init(). These variables are all bound to the corresponding command line option and are updated in parse(). - In a few cases, the command line option does not directly map to a bound variable (e.g. -b to set buffer format, -p/-pk/-pc to set extra formatting options, etc.) In these cases the option values are read after parsing and update the public instance variable. One public-visible change is that --list, which used to support an optional argument, has been broken into two options. --list now always displays all fields, and a new option --list-source displays fields for a specific source. This is because the cxxopts library has a bug (jarro2783/cxxopts#104, jarro2783/cxxopts#211) that does not parse implicit options correctly when specified as "--list <source>". --list=<source> or --list<source> would work, but I wanted to support space separated options and I expect use of --list with a source was uncommon. Signed-off-by: Mark Stemm <[email protected]>
mstemm
added a commit
to falcosecurity/falco
that referenced
this issue
Feb 9, 2022
Fill in an initial falco::app::cmdline_options class using cxxopts library to hold options: - falco::app::cmdline_options contains a cxxopts::Options object to parse options and a cxxopts::ParseResult to hold the result. - The only meaningful public method is parse() which parses argc/argv and returns true/false + error. - The parsed options are all public instance variables of the object and generally use the same names of the corresponding variables in the old falco_init(). These variables are all bound to the corresponding command line option and are updated in parse(). - In a few cases, the command line option does not directly map to a bound variable (e.g. -b to set buffer format, -p/-pk/-pc to set extra formatting options, etc.) In these cases the option values are read after parsing and update the public instance variable. One public-visible change is that --list, which used to support an optional argument, has been broken into two options. --list now always displays all fields, and a new option --list-source displays fields for a specific source. This is because the cxxopts library has a bug (jarro2783/cxxopts#104, jarro2783/cxxopts#211) that does not parse implicit options correctly when specified as "--list <source>". --list=<source> or --list<source> would work, but I wanted to support space separated options and I expect use of --list with a source was uncommon. Signed-off-by: Mark Stemm <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have found that when using the following option definition:
("g,go","go mode selection",cxxopts::value<uint32_t>()->implicit_value("1")->default_value("0"))
and using the "-g" specifier the implicit value will always be delivered regardless of the value specified on the command line by the call
result["g"].as<uint32_t>()
If, however, you use --go=10 you get the correctly specified command line value of 10
The text was updated successfully, but these errors were encountered: