We were just calling Help() when a user set the --help flag. You could
overwrite how the help subcommand worked with SetHelpFunc, but not now
the --help flag worked.
Today the HelpFunc() seemed to be tailor built for the `help`
subcommand. Which has a rather weird purpose as its `Run` needs to
find the actual command we want to get help about.
Instead make the HelpFunc() for a command be about that command,
rather than having it search for some other command...
```go
package main
import (
"github.com/spf13/cobra"
"github.com/spf13/pflag"
)
func main() {
cmd := &cobra.Command{
Use: "min",
Short: "minimal command",
Run: func(_ *cobra.Command, _ []string) {},
}
pflag.String("oncmdline", "oncmdline", "oncmdline")
cmd.Execute()
}
```
Is a minimal cobra program. When --help is displayed without this patch
you only get:
But with the patch --oncmdline is shows under flags.
The template had gotten out of control. It was basically unparsable.
This does a little more work in functions and a little less in the
template. Overall it should be basically the same. It might output the
'additional help topics' in a couple of fewer places, but I doubt people
complain too much...
Calling `cobra-test echo times one two turkey` where `one` and `two` are
valid arguments but `turkey` is not now results in.
Error: invalid argument "turkey" for "cobra-test echo times"
Run 'cobra-test echo times --help' for usage.
Inside Command.Execute() we were checking for pflag.ErrHelp. But
Command.execute() never returns that value. It just complicates the code
and isn't used.
We had lots of quirky if statements like `commandFound.Name() ==
c.Name() && len(stripFlags(args, c)) > 0 && commandFound.Name() !=
args[0]` which embeed all sorts of artifacts which are hard to parse. So
in general, just try to simplify and make stuff readable.
This fixes a problem where if you had a root command and a grand child
with the same name, the parser would break and would not run the
grandchild. The code was special casing if the immediate child had the
same name, but didn't handle grand-children
by now, if someone calls: `program --validflag unknowncommand` the
output will be:
```
Error: unknown command "--validflag"
Run 'program help' for usage.
```
This patch strips out flags so the unknown command is printed:
```
Error: unknown command "unknowncommand"
Run 'program help' for usage.
```
We had some stuff that created a new empty []string if args was already
and empty string (why?)
We had some stuff that called Help() if it wasn't runnable (but
.execute() already does that)
Just remove the special case stuff.
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...
The additional help topics were really hard to ever get to show. The
required conditionals were difficult to meet and did not seem to really
be logical.
Problems I see:
1) the top level command could never have additional topics.
2) you must have at least one sibling command AND one subcommand
3) we had the AND above, but then test both conditionals a second time
4) if the sub command was runnable we wouldn't print anything
5) if the sibling commands were not runnable we wouldn't print anything
4+5) it's possible that we printed "Additional help topics:" with nothing following it
6) We always printed ourselves as a sibling in the additional info
Whew, I think I fixed all of those! Again, using
https://github.com/eparis/readable-golang-template
I'm actually able to visualize the template and see this craziness.
The conditionals BEFORE this change:
{{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}}
The conditionals AFTER this change:
{{if or (.HasHelpSubCommands) (.HasRunnableSiblings)}}
Additional help topics:
{{if .HasHelpSubCommands}}
{{range .Commands}}
{{if not .Runnable}}
{{rpad .CommandPath .CommandPathPadding}} {{.Short}}
{{end}}
{{end}}
{{end}}
{{if .HasRunnableSiblings }}
{{range .Parent.Commands}}
{{if .Runnable}}
{{if not (eq .Name $cmd.Name) }}
{{rpad .CommandPath .CommandPathPadding}} {{.Short}}
{{end}}
{{end}}
{{end}}
{{end}}
{{end}}
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.
Eric Paris