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
Albert Nigmatzianov