The special case code to handle a runnable root command had some
problems. It was noticed that if you created a runnable root and a
subcommand. And the subcommand was then executed with both a valid and
invalid flag, the error message was about the valid flag being invalid.
For example
./command subcommand --goodflag=10 --badflag=10
Would fail and tell you that --goodflag was an invalid flag. Instead if
we just do away with the special Command.execute() for the root command
the parser for subcommand is what prints the error and it gets it
right...
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
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.
A command can now be invoked with a prefix of its own name, assuming that
prefix is unambiguous (ie it isn't also a prefix of any sibling command's
name).
Eric Paris