CLI11
CLI11 copied to clipboard
CLIUtils
Options parse --help as argument to option
If I run a command where option1 is configured for 0 or 1 inputs and I try to open the help menu, it doesnt open:
cmd subcmd --option1 --help
It complains about --option1, because it accepts --help as an input to the option. Is this really expected behavior, or is there any way to override this? Double dashes indicate a new option, and the fact that it is configured to accept 0 inputs as well as 1 input, and --help is a valid new option, should tell the parser to not accept --help as input.
are you on master or 1.9? There were some changes in how that situation might be handled after the 1.9 release.
Does --option1 require an argument? If so, then --help is a valid argument. How else would you give an option with two dashes (or, more common, one dash, like, -1)? If it's a variable length argument, though, I think including 0 to 1, then this will trigger as an option instead of an argument.
(If you know you will never have at least --x arguments, that behavior might be reasonable to configure, though).
Not sure if it was clear from the original post, but the option can be of variable length with 0 to 1 inputs ( ->expected(0,1) ) . Even then, --help is passed as an argument. I often find that even though the option requires an argument, I will type --help right after sometimes to bring up the help menu anyways. I know others do this too, so shouldn't there be an option to make --help a reserved keyword that will call for help?
@henryiii Not sure if this is related, but if I add a positional option to a subcommand with ->expected(0,1), it is not parsed correctly