There's no official way to see help messages for nested subcommands.
The usage for kcctl is easy to view, via kcctl help, kcctl -h, or kcctl --help, and provides a list of all commands along with a brief description of what each does.
The usage for any top-level commands (e.g., kcctl apply) is also easy to view, via kcctl help <command> (e.g., kcctl help apply or kcctl help delete).
If any of these commands contains nested subcommands, the subcommands are listed with a brief description of what they do. For example:
> kcctl help delete
Usage: kcctl delete [<args>...] [COMMAND]
Deletes connectors
[<args>...]
Commands:
connector Deletes specified connector
However, there's no way to get usage information for those nested subcommands that doesn't involve hacks like throwing in an unrecognized flag (e.g., -h) that causes the command to exit with a non-zero status and print an error message. For example:
> kcctl delete connector -h
Unknown option: '-h'
Usage: kcctl delete connector [-e] [CONNECTOR NAME...]
Deletes specified connectors
[CONNECTOR NAME...] Name of the connector
-e, --reg-exp use CONNECTOR NAME(s) as regexp pattern(s) to apply
on all connectors
We should make it as easy as possible for users to learn about the syntax/semantics of subcommands. Some options for this include:
kcctl help <command> <subcommand> (right now this only shows the usage information for <command>)kcctl <command> help <subcommand> (right now this prints an error message and then the usage information for <command>)kcctl <command> <subcommand> -h and/or kcctl <command> <subcommand> --help (right now this prints an error message and then the usage information for <subcommand>)kcctl <command> <subcommand> help (right now this invokes the subcommand with an argument of help)
IMO option 1 has the most intuitive syntax, but may be difficult to implement. Options 2 and 3 are straightforward to implement via the existing CommandLine.HelpCommand class and mixinStandardHelpOptions annotation option, respectively. Option 4 is also straightforward to implement with the CommandLine.HelpCommand class, but is a little uglier as it causes the subcommand to have its own subcommand named help, which pollutes usage messages a bit.
I'd like to implement option 3 unconditionally (-h is a deeply-ingrained reflex for many CLI users), and then either option 1 (if it can be done with reasonable effort) or option 2 (if option 1 can't be done). Interested in others' perspectives!
There's no official way to see help messages for nested subcommands.
The usage for
kcctlis easy to view, viakcctl help,kcctl -h, orkcctl --help, and provides a list of all commands along with a brief description of what each does.The usage for any top-level commands (e.g.,
kcctl apply) is also easy to view, viakcctl help <command>(e.g.,kcctl help applyorkcctl help delete).If any of these commands contains nested subcommands, the subcommands are listed with a brief description of what they do. For example:
However, there's no way to get usage information for those nested subcommands that doesn't involve hacks like throwing in an unrecognized flag (e.g.,
-h) that causes the command to exit with a non-zero status and print an error message. For example:We should make it as easy as possible for users to learn about the syntax/semantics of subcommands. Some options for this include:
kcctl help <command> <subcommand>(right now this only shows the usage information for<command>)kcctl <command> help <subcommand>(right now this prints an error message and then the usage information for<command>)kcctl <command> <subcommand> -hand/orkcctl <command> <subcommand> --help(right now this prints an error message and then the usage information for<subcommand>)kcctl <command> <subcommand> help(right now this invokes the subcommand with an argument ofhelp)IMO option 1 has the most intuitive syntax, but may be difficult to implement. Options 2 and 3 are straightforward to implement via the existing
CommandLine.HelpCommandclass andmixinStandardHelpOptionsannotation option, respectively. Option 4 is also straightforward to implement with theCommandLine.HelpCommandclass, but is a little uglier as it causes the subcommand to have its own subcommand namedhelp, which pollutes usage messages a bit.I'd like to implement option 3 unconditionally (
-his a deeply-ingrained reflex for many CLI users), and then either option 1 (if it can be done with reasonable effort) or option 2 (if option 1 can't be done). Interested in others' perspectives!