Consider this example/test source code:

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();}

Runningcargo 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 typeRun 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 thereis 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.)