The `see_also` section for child commands would include only the name of
the commands. This adds the whole path, similar to how it's done for the
other documentation formats.
Reaching out on behalf of KubeVirt, an add-on for Kubernetes, enabling
users to run Virtual Machines on Kubernetes pods.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
Since go 1.13 you can wrap errors. This make it no longer possible to
compare with `==`, instead you have to compare with `errors.Is()`.
I noticed this problem because -h was no longer working after I stared
wrapping the errors in my custom FlagErrorFunc function.
Note that this is only a problem when a custom help flag is defined.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Fixes#1734
Tab characters that introduce completion descriptions weren't properly
being handled with bash v3. This change fixes that.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
Previously the generated zsh completion script started with the line
#compdef _<command> <command>
where <command> is the command that the zsh completion script is
generated for.
This enabled completions for both <command> and _<command>, but
_<command> is the completion function itself and should not be
completed. Furthermore, attempting to autocomplete _<command> (e.g.
typing "_<command><Space><Tab>" in a zsh shell) causes zsh to hang.
This commit fixes the #compdef line to only complete <command>, not
_<command>.
Co-authored-by: Arvid Norlander <VorpalBlade@users.noreply.github.com>
Not that it'd really matter that much performancewise given the level we
are at for this case, but this change makes the short circuit roughly
twice as fast on my box as it was for the 1000 rounds done in
marckhouzam/cobra-completion-testing.
Perhaps more importantly, this makes the code arguably slightly cleaner.
If the list of candidates has no descriptions, short circuit all the
description processing logic, basically just do a `compgen -W` for the
whole list and be done with it.
We could conceivably do some optimizations like this and more when
generating the completions with `--no-descriptions` in Go code, by
omitting some parts we know won't be needed, or doing some things
differently. But doing it this way in bash, the improvements are
available also to completions generated with descriptions enabled when
they are invoked for completion cases that produce no
descriptions. The result after this for descriptionless entries seems
fast enough so it seems there's no immediate need to look into doing
that.
For legacy bash completions, similarly as commit
4f0facbcee is for bash completions v2.
As a side effect, fixes test suite with shellcheck 0.8.0 installed;
apparently the 0.7.0 that's in GitHub Actions' ubuntu-latest at the
moment does not flag the array quoting related issue that was provoked
from 0.8.0 before this change.
Refactor to remove two loops over the entire list of candidates.
Format descriptions only for completions that are actually going to be
displayed, instead of for all candidates.
Format descriptions inline in completions array, removing need for a
command substitution/subshell and a printf escape per displayed
completion.
Using a command substitution, i.e. a subshell, with `printf` is
expensive for this purpose. For example `__*_format_comp_descriptions`
is run once for each completion candidate; the expense adds up and
shows when there are a lot of them.
This change adds two features for dealing with flags:
- requiring flags be provided as a group (or not at all)
- requiring flags be mutually exclusive of each other
By utilizing the flag annotations we can mark which flag groups
a flag is a part of and during the parsing process we track which
ones we have seen or not.
A flag may be a part of multiple groups. The list of flags and the
type of group (required together or exclusive) make it a unique group.
Signed-off-by: John Schnake <jschnake@vmware.com>
Without this, slightly older versions of zsh fail to correctly parse the output of the __complete
command. Tested that with zsh 5.0.2 and zsh 5.8. Since this is just correctly quoting the output of
a command, it shouldn't cause any compatibility issues.
- Only label issues after feb 01, 2022
- Apply lifecycle/stale after 60 days
- Close issue and apply lifecycle/rotten after another 30 days
Signed-off-by: John McBride <jmcbride@vmware.com>
These tests make sure we don't break backwards-compatibility with
respect to the current behaviour of legacyArgs().
See #1500 for the back-story.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
Zoran Regvart