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
takes_value()
parameters with default_value()
are shown in USAGE like mandatory
#1140
Comments
takes_value()
parameters with default_value()
are shown in USAGE like requiredtakes_value()
parameters with default_value()
are shown in USAGE like mandatory
It's particularly annoying that this shadows all other flags. So App::new("Test")
.arg(
Arg::with_name("required")
.required(true)
)
.arg(
Arg::with_name("defaulted")
.takes_value(true)
.short("d")
.long("defaulted")
.default_value("1")
)
.arg(
Arg::with_name("another")
)
.get_matches_from(vec!["prog"]); produces
instead of
|
The error messages show "used arguments" i.e. "this possibly what the command you just tried running should have been run" But yes, defaults get thrown in there too. I can do some work to remove default values from error messages. This wouldn't however "turn off" the shadowing. With that fix
Would become
I'm open to adding an option to turn off this "smart usage" so that the error would become just the default:
(you can already kind of do this by just supplying your own usage string, which will get used no matter what.) |
If someone wants to add this setting to disable the "smart usage" I'd be happy to mentor it. Removing the defaults from the usage string is probably more complicated than just adding this setting. |
I see. I'll consider the possible ways to proceed from here, after I take a look at the clap sources when I'm done with other things. For the time being, I have another alternative to posit. How hard would it be to, at least, make the defaulted but non-required arguments be printed in square brackets, so as to convey their non-mandatory nature? I.e. something like
Or do you think that this would violate user's expectations, making them believe that they have to put "--defaulted" in square brackets in order to use it? |
It would be fine, but almost as much work as simply not printing the defaults (which is a slightly better solution IMO). In the source for either of these two fixes, when clap is printing the usage string, it doesn't know if something is a default value or not, it just sees an argument was used (used by user, or used by default). So it would require re-looping through the used arguments to see if they have a default, and if so if the value that was used was in fact the default. |
Workaround for clap bug: clap-rs/clap#1140 where the arg will always be displayed in the usage string.
Workaround for clap bug: clap-rs/clap#1140 where the arg will always be displayed in the usage string.
In some ways, this reminds me of #3076 |
This was fixed by #2609 |
Affected Version of clap
clap 2.29.0
Expected Behavior Summary
When command line parsing fails, a USAGE section is shown. This usage section should NOT contain non-required parameters with default values. Suppose there are two parameters, "required" and "defaulted", and the user didn't specify the required one. The output should be as follows
Actual Behavior Summary
Defaulted option parameters are mentioned in parse error help for no particular reason, confusingly looking like they're mandatory, even if they're
required(false)
.Steps to Reproduce the issue
Utilize the following code. Note that if one comments out ".default_value()", the parse error no longer contains the mention of the defaulted parameter, as expected.
Sample Code or Link to Sample Code
The text was updated successfully, but these errors were encountered: