As persistent flags of parents can only be added, we don't need to always
check them every time, so make updateParentsPflags return only added flags.
Performance improvement:
benchmark old ns/op new ns/op delta
BenchmarkInheritedFlags-4 5595 4412 -21.14%
BenchmarkLocalFlags-4 3235 2667 -17.56%
benchmark old allocs new allocs delta
BenchmarkInheritedFlags-4 39 24 -38.46%
BenchmarkLocalFlags-4 21 15 -28.57%
benchmark old bytes new bytes delta
BenchmarkInheritedFlags-4 1000 600 -40.00%
BenchmarkLocalFlags-4 544 408 -25.00%
I think It's more obvious now to understand the inheritance of flags.
Fix#403Fix#404
Performance improvements:
benchmark old ns/op new ns/op delta
BenchmarkInheritedFlags-4 6536 5595 -14.40%
BenchmarkLocalFlags-4 3193 3235 +1.32%
benchmark old allocs new allocs delta
BenchmarkInheritedFlags-4 49 39 -20.41%
BenchmarkLocalFlags-4 23 21 -8.70%
benchmark old bytes new bytes delta
BenchmarkInheritedFlags-4 2040 1000 -50.98%
BenchmarkLocalFlags-4 1008 544 -46.03%
* Fix shellcheck
Before this change:
In - line 204:
declare -F $next_command >/dev/null && $next_command
^-- SC2086: Double quote to prevent globbing and word splitting.
--- FAIL: TestBashCompletions (0.34s)
bash_completions_test.go:138: shellcheck failed: exit status 1
* Avoid storing pointer to nil
Before this change, the new test fails with:
--- FAIL: TestSetOutput (0.00s)
command_test.go:198: expected setting output to nil to revert back to stdout, got <nil>
If one ran a command like
./root --boolFlag subcmd1 subcmd2
Thing worked fine. The code recognized that --boolFlag followed by a
space meant the next word was not the argument to --boolFlag. But other
flag types with a NoOptDefValue (like a Count flag) would not ignore the
"argument". On a command like:
./root --countflag subcmd1 subcmd2
The processor, when looking for a subcommand, would first throw out the
`--countflag subcmd1` and then look for subcmd2 under root.
The fix is to ignore the next word after any NoOptDefVal flag, not just
boolean flags.
The default pflag error is to only print the bad flag. This enables an application
to include a usage message or other details about the error.
Signed-off-by: Daniel Nephin <dnephin@gmail.com>
If a user specifies a flag to a command which doesn't make sense to a
subcommand do not show subcommands as a suggestion.
This also changes things to show both 'required flags' and 'commands'
instead of only 'required flags'
If a command has one flag which is hidden, it should not, for
instance, show the `Flags: ` heading. Likewise there are other
items in the help template which should respect hidden/deprecated
state.
* Moving final return outside of if-else
* Removing type declarations that Go can infer from values
* Cleaning up some existing comments
* Changing snake_case variables to camelCase
so that full path to the executable or a renamed executable
parses command-line arguments correctly as before.
Special thanks to @apriendeau for discovering "go test -v" failing
and for providing the initial workaround, see #155 and subsequent
discussions.
The flags usage template from pflags has a trailing \n. We need to
include a newline in case there are no flags in our template. This will
trim the newline from the end of the flags from pflag and we can do it
right outselves.
This slightly changes IsAvailableCommand in that a non-runnable command
with a runnable subcommand is now 'Available'
We also use IsAvailableCommand in the rest of the codebase instead of
half kinda sorta doing it incorrectly other places.
Added the ability to have hidden commands that cobra will still run as intended, however they won't show up in any usage/help text
adding internal field to command
private is a better name
hiding private commands in default help/usage
opting for 'hidden' over 'private'
updating all 'help command' checks to exclude hidden commands
updating how commands are displayed in usage/help text by updating/adding some methods. added tests for hidden/deprecated commands
making command hidden when testing hidden command execution
test now leverage the included suite and are much less custom. also removed deprecation tests, once I discovered them in cobra_test.go
updating hidden command test to be more reliable
removing unnecessary () when checking len(c.Deprecated)
updating command comments to be godoc friendly
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.
```
Albert Nigmatzianov