-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Argument value should take precedence over subcommand with the same name #1031
Comments
Agreed. Sorry for the delay, I've been traveling for work for the past month and a half. I'll mark this as a bug. A workaround in the meantime is to use Another workaround is to disallow subcommands when a valid arg has been found. I.e. disallow the |
…h a subcommand name, its parsed as a value When using args with `multiple(true)` on options or positionals (i.e. those args that accept values) and subcommands, one needs to consider the posibility of an argument value being the same as a valid subcommand. By default `clap` will parse the argument in question as a value *only if* a value is possible at that moment. Otherwise it will be parsed as a subcommand. In effect, this means using `multiple(true)` with no additional parameters and a possible value that coincides with a subcommand name, the subcommand cannot be called unless another argument is passed first. As an example, consider a CLI with an option `--ui-paths=<paths>...` and subcommand `signer` The following would be parsed as values to `--ui-paths`. ``` $ program --ui-paths path1 path2 signer ``` This is because `--ui-paths` accepts multiple values. `clap` will continue parsing values until another argument is reached and it knows `--ui-paths` is done. By adding additional parameters to `--ui-paths` we can solve this issue. Consider adding `Arg::number_of_values(1)` as discussed above. The following are all valid, and `signer` is parsed as both a subcommand and a value in the second case. ``` $ program --ui-paths path1 signer $ program --ui-paths path1 --ui-paths signer signer ``` Closes #1031
rustc 1.18.0 / clap 2.26.0
When using the
argument value
notation (as opposed toargument=value
), when a top-level argument has a value with the same name as a subcommand, Clap parses this as running the subcommand and using the top-level argument with no value (even though one is required).Sample Code / Steps to Reproduce the Issue
Thanks!
The text was updated successfully, but these errors were encountered: