I wrote https://github.com/eparis/readable-golang-template which
converts golang templates into something structured around the
conditionals. Obviously you can't just USE the output, but you can SEE
the problems. In this case the output shows something like:
{{if .HasParent}}
{{if and (gt .Commands 0) (gt .Parent.Commands 1) }}
Additional help topics:
{{if gt .Commands 0 }}
{{range .Commands}}
{{if not .Runnable}}
{{rpad .CommandPath .CommandPathPadding}} {{.Short}}
{{end}}
{{end}}
{{end}}
{{if gt .Parent.Commands 1 }}
{{range .Parent.Commands}}
{{if .Runnable}}
{{if not (eq .Name $cmd.Name) }}
{{end}}
{{rpad .CommandPath .CommandPathPadding}} {{.Short}}
{{end}}
{{end}}
{{end}}
{{end}}
{{end}}
We have a completely unused "{{if not (eq .Name $cmd.Name) }}"
Move the {{end}} after the {{rpad...}}
Some projects pick up flags from other projects they include. A great
example would be projects that use glog and thus get all of those flags.
Kubernetes, for example, merges those flags manually into its commands.
This was reported in https://github.com/spf13/cobra/issues/44
What this patch does is merge those flags into the PersistentFlags on
the highest parent. This allows kubernetes to stop having to merge
things themselves...
If the command has not set an output explicitly everything will go to
stderr. This makes a lot of sense, but is a huge PITA for people who
want to be able to grep the help output. It is very common for users to
want to do
command --help | grep flag
This patch fixes that by default help output (but not error output like
an invalid command) to stdout instead of defaulting to stderr.
This method removes children commands of an existing command.
This allows to build CLI clients that can be extended by 3rd party tools,
for instance by adding commands _and replacing the “version” command_.
For now the 1st defined command will be executed, so it is not possible
to override an existing command. But anyway, deleting old command then
adding a new one is the ultimate way to be certain there is no
confusion.
The current (desired) behavior when a Command specifies a flag that
has the same name as a persistent/inherited flag, is that the local
definition takes precedence. This change updates the various
Flag subset functions to respect that behavior:
* LocalFlags: now returns only the set of flags and persistent flags
attached to the Command itself.
* InheritedFlags: now returns only the set of persistent flags inherited
from the Command's parent(s), excluding any that are overwritten by a
local flag.
* NonInheritedFlags: changed to an alias of LocalFlags.
* AllPersistentFlags: removed as not very useful; it returned the set
of all persistent flags attached to the Command and its parent(s).
Default UsageTemplate updated to use LocalFlags and InheritedFlags
This method removes children commands of an existing command.
This allows to build CLI clients that can be extended by 3rd party tools,
for instance by adding commands _and replacing the “version” command_.
For now the 1st defined command will be executed, so it is not possible
to override an existing command. But anyway, deleting old command then
adding a new one is the ultimate way to be certain there is no
confusion.
A corner case exists where c.Runnable() is not checked
before c.Run() is called, thus a nil c.Run is executed
leading to "panic: runtime error: invalid memory address
or nil pointer dereference".
This patch adds an extra c.Runnable() check in execute()
to catch that corner case.
Fixes#37.
For a single root command with a Run method, the help output still
contains 'help [command]' as a subcommand (because Help is always
added). Since the only subcommand would be 'help', the help is better
off omitted.
This change allows a command to be used both as a subcommand
or a root command without having to define a custom help that elides
the help command when no subcommands are added. Instead, the default
help command is only added when subcommands are present.
If, for some reason, you have an application with some name "foo", and your
app has a subcommand "foo", cobra should behave properly when you call
"foo foo", and it should also behave if you call "foo f".
These changes verify both of these cases and ensure cobra responds properly.
This fixes some issues that appear when testing prefix invocations. Since the
root command lists weren't being cleared, the list would persist between
tests, so there would be multiple instances of each command. Then, if you
tried to match a prefix of one of those commands, you'd get two matches (one
for each instance) and the command would fail.
Resetting the root command lists prevents them from persisting between tests,
resolving this issue.
