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 argh::FromArgs;#[derive(FromArgs)]/// ExamplestructArgs{#[argh(subcommand)]subcommand:Subcommand,}#[derive(FromArgs)]#[argh(subcommand)]enumSubcommand{One(SubcommandOption1),}#[derive(FromArgs)]#[argh(subcommand, name = "one")]/// First subcommandstructSubcommandOption1{#[argh(positional)]/// small numberone:u8,}fnmain(){let _args:Args = argh::from_env();}
Running cargo run -- one 257 (or building and then running ./test.exe one 257) on this will predictably fail, because the number 257 doesn't fit inside a u8. But let's look at the error message that gets returned on that failure:
Error parsing positional argument 'one' with value '257': number too large to fit in target type
Run test.exe --help for more information.
But note the jump! That's not the help page for the subcommand that contains the positional argument 'one'; that's the root help page for the overall command. Users are being directed to the wrong place! They'll need to manually navigate their way to finding the subcommand's help menu from there. Users less familiar with how argh organizes its help menus might not even realize that there is a subcommand help menu they should be accessing instead.
I suggest, as an alternative, that, when a subcommand returns an error of this sort, the error message's direction-to-the-help-menu should point directly at the subcommand which threw the error. So, for instance, in this case, Run test.exe one --help for more information..
(All example code here was compiled and run on Windows 10, using argh 0.1.12.)
The text was updated successfully, but these errors were encountered:
Consider this example/test source code:
Running
cargo run -- one 257
(or building and then running./test.exe one 257
) on this will predictably fail, because the number 257 doesn't fit inside a u8. But let's look at the error message that gets returned on that failure:But note the jump! That's not the help page for the subcommand that contains the positional argument 'one'; that's the root help page for the overall command. Users are being directed to the wrong place! They'll need to manually navigate their way to finding the subcommand's help menu from there. Users less familiar with how argh organizes its help menus might not even realize that there is a subcommand help menu they should be accessing instead.
I suggest, as an alternative, that, when a subcommand returns an error of this sort, the error message's direction-to-the-help-menu should point directly at the subcommand which threw the error. So, for instance, in this case,
Run test.exe one --help for more information.
.(All example code here was compiled and run on Windows 10, using argh 0.1.12.)
The text was updated successfully, but these errors were encountered: