Currently it just prints the help message and exits 0.
We do this by modifying the helpCommand and helpSubcommand cli.Commands
to return an error if they are called with an unknown subcommand. This
propogates up to the app which exits with 3 and prints the error.
Thanks to @danslimmon for the initial approach!
Fixes#276
plus breaking out "setup" portion of `App.Run` into its own method, cleaning up
some bits of the help templates, and allowing for runtime opt-in of displaying
template errors to stderr.
This is a way to provide hidden flags for app, command and subcommands
For example:
--generate-bash-completion global flag shouldn't be printed along
with other flags as it might generally confuse people into thinking
that 'generate' in-fact would generate a bash completion file for them
to be used along with their app.
Also in general one would want to hide some flags for their apps.
Just place all subcommands in categories, the default category will be
"" which will properly format the output (and group commands that have
no category).
Also allow subcommands to have categories.
Lastly, augment the test to check the output.
There is a panic in printHelp that can be trivially triggered when the
shell closes os.Stdout. This happens, for example, when data is piped
between a cli app and something else.
See https://github.com/helm/helm/issues/387
When processing the flags for -h/--help and -v/--version, only check
the flags in checkVersion() and checkHelp() instead of also printing
the associated message.
This fixes the problem of `app -h` and `app -v` printing their output
twice. The doubling was caused by printing the message once for each
registred alias for the given flags (-h/--help and -v/--version).
Resolves#285
Now the exit code can be returned by BeforeFn, ActionFn and AfterFn.
The `os.Exit` function is not called by this packaged
This closes#66 and closes#164
But update signature to take a writer. This is a backwards incompatible
change for those overriding the HelpPrinter, but the hope is that this
feature is largely unused and the usage is easily updated.
- the command name is "" and HasName was returning true for an empty
ShortName.
- the Show method wasn't aware that command name was just "" and
returned the first subcommand.
