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
Consider a basic minimal bit of argh code centered on subcommands, something like this:
use argh::FromArgs;#[derive(FromArgs)]/// ExamplestructArgs{#[argh(subcommand)]subcommand:Subcommand,}#[derive(FromArgs)]#[argh(subcommand)]enumSubcommand{One(SubcommandOption1),Two(SubcommandOption2),}#[derive(FromArgs)]#[argh(subcommand, name = "one")]/// First subcommandstructSubcommandOption1{}#[derive(FromArgs)]#[argh(subcommand, name = "two")]/// Second subcommandstructSubcommandOption2{}fnmain(){let _args:Args = argh::from_env();}
If the executable compiled from this code is run directly, without any args passed—cargo run or ./target/debug/text.exe—the following help text is displayed:
One of the following subcommands must be present:
help
one
two
Run test.exe --help for more information.
This is somewhat inconsistent. On the one hand it supposedly needs one of those subcommands; on the other hand the recommendation-for-more-information is to run it without one of those subcommands, with only the --help flag.
Moreover, if one in fact follows either half of that advice—running it either with the help subcommand or the --help flag (which are, as far as I can tell, in practice synonymous)—then one will get this readout:
Usage: test.exe <command> [<args>]
Example
Options:
--help display usage information
Commands:
one First subcommand
two Second subcommand
...wherein, suddenly, there's no help subcommand listed, while the --help flag is suddenly listed more centrally / less as-an-afterthought.
So, overall, it seems like there's some inconsistent behavior going on here. It doesn't seem like argh is quite sure whether it wants its help-menu-access to be primarily via subcommand (with the flag as a nondefault option for those who particularly need it) or whether it wants its help-menu-access to be primarily via flag (with the subcommand as a nondefault option for those who particularly need it). And I suspect that it would be better if argh were more committed in one direction or the other, rather than split halfway between the two as it currently is.
(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 a basic minimal bit of argh code centered on subcommands, something like this:
If the executable compiled from this code is run directly, without any args passed—
cargo run
or./target/debug/text.exe
—the following help text is displayed:This is somewhat inconsistent. On the one hand it supposedly needs one of those subcommands; on the other hand the recommendation-for-more-information is to run it without one of those subcommands, with only the
--help
flag.Moreover, if one in fact follows either half of that advice—running it either with the
help
subcommand or the--help
flag (which are, as far as I can tell, in practice synonymous)—then one will get this readout:...wherein, suddenly, there's no
help
subcommand listed, while the--help
flag is suddenly listed more centrally / less as-an-afterthought.So, overall, it seems like there's some inconsistent behavior going on here. It doesn't seem like argh is quite sure whether it wants its help-menu-access to be primarily via subcommand (with the flag as a nondefault option for those who particularly need it) or whether it wants its help-menu-access to be primarily via flag (with the subcommand as a nondefault option for those who particularly need it). And I suspect that it would be better if argh were more committed in one direction or the other, rather than split halfway between the two as it currently is.
(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: