You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
use clap::{Parser,Subcommand};#[derive(Parser,Debug)]#[clap(subcommand_required = true)]structArgs{#[clap()]names:Vec<String>,#[clap(subcommand)]action:Action,}#[derive(Subcommand,Debug)]enumAction{Greet,}fnmain(){for name inArgs::parse().names{println!("hey {}", name);}}
Steps to reproduce the bug with the above code
See help message
$ cargo r -- -hcliUSAGE: cli [NAMES]... <SUBCOMMAND>ARGS: <NAMES>... OPTIONS: -h, --help Print help informationSUBCOMMANDS: greet help Print this message or the help of the given subcommand(s)
Run program according to help message
$ cargo r -- name1 greet
Actual Behaviour
When I run the program according to the help message usage, it returns an error
$ cargo r -- name1 greeterror: 'cli' requires a subcommand but one was not providedUSAGE: cli [NAMES]... <SUBCOMMAND>For more information try --help
Expected Behaviour
The syntax given by the help message should work, or the help message should give a valid syntax.
$ cargo r -- name1 greethey name1
Or, there should be an assertion somewhere about this specific configuration, since it also doesn't work to pass the names after the subcommand (there is no way to pass names).
The syntax given by the help message should work, or the help message should give a valid syntax.
This requires the user doing this intentionally and designing their CLI so that a valid positional value never conflicts with a subcommand and to never use external_subcommand
Or, there should be an assertion somewhere about this specific configuration, since it also doesn't work to pass the names after the subcommand (there is no way to pass names).
Mhm, having an assertion for this specific case would be a clear way to enforce that as a way not to design a cli.
With that/when assertion is added I think this issue is resolved.
#3721 is a little different because the positional argument there is global.
For that issue, I do think the help message should be different; I'm not sure I followed your comment there. Using the format given by the help message doesn't actually work, you have to put the positional argument at the end.
In #3721, the bug is that we allowed unbound positional arguments at the same level as subcommands; that is unambiguous and we can't really do much about it. This is why I was suggesting we prevent users from even doing this, like here. This is independent of global(true).
Please complete the following tasks
Rust Version
rustc 1.61.0 (fe5b13d68 2022-05-18)
Clap Version
3.2.8
Minimal reproducible code
Steps to reproduce the bug with the above code
$ cargo r -- name1 greet
Actual Behaviour
When I run the program according to the help message usage, it returns an error
Expected Behaviour
The syntax given by the help message should work, or the help message should give a valid syntax.
Or, there should be an assertion somewhere about this specific configuration, since it also doesn't work to pass the names after the subcommand (there is no way to pass names).
Additional Context
Related: #3721
I'm able to pass names when
names
is global, but like is mentioned in the related issue, the help message shows the order differently than is valid.Apologies if this is the same issue as #3721.
Debug Output
The text was updated successfully, but these errors were encountered: