Use either command or subcommand consistently in help messages.

[itsgreggreg]

Is there a difference between a command and a subcommand? If not perhaps the help message should use one word consistently. Perhaps most ambiguously, usage is cargo ... [SUBCOMMAND] but help is cargo help <command>

$ cargo | grep -i command       
    cargo [+toolchain] [OPTIONS] [SUBCOMMAND]
        --list                     List installed commands
Some common cargo commands are (see all commands with --list):
See 'cargo help <command>' for more information on a specific command.

$ cargo list | grep -i command
Installed Commands:
    git-checkout         This subcommand has been removed

[epage]

. Perhaps most ambiguously, usage is cargo ... [SUBCOMMAND] but help is cargo help

This is fixed in clap3

From one of the tests:

myapp-help 
Print this message or the help of the given subcommand(s)

USAGE:
    myapp help [SUBCOMMAND]...

ARGS:
    <SUBCOMMAND>...    The subcommand whose help message to display

OPTIONS:
    -h, --help    Print custom help text

With that said, clap3 also includes App::subcommand_value_name and App::subcommand_help_heading to customize how this shows up. However, error messages is not customizable and help text requires modifying the argument's help / subcommands about.

[ehuss]

Yea, I can see how it is a bit inconsistent. I'm not sure if there is a strict definition of what is a "command" vs a "subcommand". For example, git usually calls all of their things "commands", but also interchangeably uses "subcommand". I guess one interpretation is that cargo is the "command" and the next arg is a "subcommand". However, I'd be reluctant to try to scrub everything to be consistent since it could potentially be disruptive (for example, changing all of the documentation).