[program_options] option recognition is too permissive
Hi, I suggest to improve options' parsing error recognition, since program_options does not throw an exception for command line options that are substrings of actual options. To be clear : assume we add an option "myoption" with the boost::program_options::options_description::add_options() function. The following command line options are recognized (program_options does not throw an exception): myoption [OK,should be recognized] myopt [BAD,should not be recognized] The following command line options are not recognized (program_options throws an exception): myoptions [OK,should not be recognized] myopr [OK,should not be recognized] I suggest program_options should parse the entire option string until reaching a '=' or ' ' character, and then trying to recognize this option. Best, Florent
Florent Teichteil wrote:
Hi,
I suggest to improve options' parsing error recognition, since program_options does not throw an exception for command line options that are substrings of actual options.
To be clear : assume we add an option "myoption" with the boost::program_options::options_description::add_options() function.
The following command line options are recognized (program_options does not throw an exception): myoption [OK,should be recognized] myopt [BAD,should not be recognized]
The following command line options are not recognized (program_options throws an exception): myoptions [OK,should not be recognized] myopr [OK,should not be recognized]
I suggest program_options should parse the entire option string until reaching a '=' or ' ' character, and then trying to recognize this option.
This is by design. There's a style option 'allow_guessing' that's on by default, but you can always pass a different style to the parse_command_line function. - Volodya
On Thu, May 22, 2008 at 12:18 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Florent Teichteil wrote:
Hi,
I suggest to improve options' parsing error recognition, since program_options does not throw an exception for command line options that are substrings of actual options.
To be clear : assume we add an option "myoption" with the boost::program_options::options_description::add_options() function.
The following command line options are recognized (program_options does not throw an exception): myoption [OK,should be recognized] myopt [BAD,should not be recognized]
The following command line options are not recognized (program_options throws an exception): myoptions [OK,should not be recognized] myopr [OK,should not be recognized]
I suggest program_options should parse the entire option string until reaching a '=' or ' ' character, and then trying to recognize this option.
This is by design. There's a style option 'allow_guessing' that's on by default, but you can always pass a different style to the parse_command_line function.
- Volodya
Sorry, I did not noticed it in the documentation. Actually, it is only mentioned in the reference. As the "allow_guessing" behavior is not very usual, it should be helpful to mention it in the tutorial? Or at least mention that one can change the behavior of the command line parser? Florent
Vladimir Prus wrote:
Florent Teichteil wrote:
I suggest program_options should parse the entire option string until reaching a '=' or ' ' character, and then trying to recognize this option.
This is by design. There's a style option 'allow_guessing' that's on by default, but you can always pass a different style to the parse_command_line function.
This caught me with some surprise, being not-unixy. (*test* Hm, seems to be like that in cygwin at least!) Isn't that a bit dangerous, as a misspelled argument may go undetected and adding a new argument (shorter substring) may cause things to go haywire? I understand why following the unix-default is a good thing, but I feel a bit worried about it. Or perhaps I needn't be? Cheers, /Marcus P.S. program_options rocks! :)
participants (3)
-
Florent Teichteil -
Marcus Lindblom -
Vladimir Prus