* Fix --version help with CommandDisplayNameAnnotation
When setting Command.Version, a --version option is added. The help
message for the --version command did not consider the command display
name:
Flags:
-h, --help help for kubectl plugin
-v, --version version for kubectl-plugin
With this change the help test is consistent with other flags:
Flags:
-h, --help help for kubectl plugin
-v, --version version for kubectl plugin
* Make command DisplayName() public
This allows using the display name in templates or other code that want
to use the same value.
* Use display name in version template
The version template used `{{.Name}}` but for plugins you want to use
`{{.DisplayName}}` to be consistent with other help output.
With this change will show:
$ kubectl plugin --version
kubectl plugin version 1.0.0
When creating a plugin without sub commands, the help text included the
command name (kubectl-plugin) instead of the display name (kubectl plugin):
Usage:
kubectl-plugin [flags]
The issue is that the usage line for this case does not use the
command path but the raw `Use` string, and this case was not tested.
Add a test for this case and fix UsageLine() to replace the command name
with the display name.
Tested using https://github.com/nirs/kubernetes/tree/sample-cli-plugin-help
When using `CommandDisplayNameAnnotation` we want to use it instead of
the command name in `--help` message or in the default help command.
With current code we get the wrong text in the --help usage text:
Flags:
-h, --help help for kubectl-plugin
And in the long description of the default help command:
$ kubectl cobraplugin help -h
Help provides help for any command in the application.
Simply type kubectl-plugin help [path to command] for full details.
The issue was hidden since the test checked only the Usage line.
Fixed by extracting a displayName() function and use it when creating
FlagSet and when formatting the default help flag usage and the help
command long description.
Enhance the TestPlugin to check all the lines including the command
name.
In this case the executable is `kubectl-plugin`, but we run it as:
kubectl plugin
And the help text should reflect the actual usage of the command.
To create a plugin, add the cobra.CommandDisplayNameAnnotation:
rootCmd := &cobra.Command{
Use: "plugin",
Annotations: map[string]string{
cobra.CommandDisplayNameAnnotation: "kubectl plugin",
}
}
Internally this change modifies CommandPath() for the root command to
return the command display name instead of the command name. This is
used for error messages, help text generation, and completions.
CommandPath() is expected to have spaces and code using it already
handle spaces (e.g replacing with _), so hopefully this does not break
anything.
Fixes: #2017
Signed-off-by: Nir Soffer <nsoffer@redhat.com>
Currently, only one of the persistent pre-runs and post-runs is executed.
It is always the first one found in the parents chain, starting at this command.
Expected behavior is to execute all parents' persistent pre-runs and post-runs.
Dependent projects implemented various workarounds for this:
- manually building persistent hook chains (in every hook).
- applying some kind of monkey-patching on top of Cobra.
This change eliminates the necessity for such workarounds
by allowing to set a global variable EnableTraverseRunHooks.
Tickets:
- https://github.com/spf13/cobra/issues/216
- https://github.com/spf13/cobra/issues/252
Signed-off-by: Volodymyr Khoroz <volodymyr.khoroz@foundries.io>
When the command searches args to find the arg matching a
particular subcommand name, it needs to ignore flag values,
as it is possible that the value for a flag might match
the name of the sub command.
This change improves argsMinusFirstX() to ignore flag values
when it searches for the X to exclude from the result.
Fixes#1831
By moving the check for help group existence to "ExecuteC()" we no
longer need groups to be added before AddCommand() is called. This
provides more flexibility to developers and works better with the use
of "init()" for command creation.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
* Add tests for grouping commands
* Adds Additional Command section in help
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
Co-authored-by: Marc Khouzam <marc.khouzam@gmail.com>
Add a global `EnableCaseInsensitive` variable to allow
case-insensitive command names.
The variable supports commands names and aliases globally.
Resolves#1382
This fixes a bug where a child flag that shadows (has the same
name as) a parent persistent flag would not be shown in the
child command's help output and the parent flag would be shown
instead under the global flags section.
This change makes the help output consistent with the
observed behavior during execution, where the child flag is
the one that is actually used.
Since go 1.13 you can wrap errors. This make it no longer possible to
compare with `==`, instead you have to compare with `errors.Is()`.
I noticed this problem because -h was no longer working after I stared
wrapping the errors in my custom FlagErrorFunc function.
Note that this is only a problem when a custom help flag is defined.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
* Fix stderr printing functions
Follow-up of #822
* Errors go to stderr as per POSIX
* use PrintErrf() instead of extra call to Sprintf()
* Error messages should always be printed to os.Stderr.
* add test case for Print* redirection
Thanks: @bukowa for the patch.
When a command request to DisableFlagParsing, it should not fail due
to a missing required flag. In fact, such a check will always fail
since flags weren't parsed!
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
Issue Reference: https://github.com/spf13/cobra/issues/1056https://github.com/spf13/cobra/pull/922 introduced a new error
type that emitted when a command was not runnable. This caused
all commands w/o a run function set to error w/ that message and a status code of 1.
This change reverts the addition of that new error. Similar
functionality can be accomplished by leveraging RunE.
As discussed in golang/go#26109, vet typecheck is enabled
in go1.11 and the command_test.go can't be compiled any
more with go1.11 due to the unread variables in the
command_test.go.
Instead of removing the unused variables, this CL reads the
variables and compares the values against the current
behavior so when the related issue is fixed, this test can
be updated accordingly.
* Add `CalledAs` method to Command (w/ tests)
The `CalledAs` method returns the name of the command or alias that
invoked the command -- as long as the command was actually invoked.
Otherwise, it returns the empty string.
The opens up possibilies for commands to behave differently based on
which alias invoked the command (in the same vein as Linux programs
which adjust their behavior based on the value of argv[0]).
* Fixed formatting
Make it so that, in the case that the root command is not runnable
but has subcommands, specifying a '--version' flag will still
run the "version" behavior.
Andre Mueller