This should help the community know who they can turn to, but also
give credit to the maintainers for all their hard work.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
Fixes#1562
Programs that don't have sub-commands can accept any number of args.
However, when doing shell completion for such programs, within the
__complete code this very __complete command makes it that the program
suddenly has a sub-command, and the call to Find() -> legacyArgs() will
then return an error if there are more than one argument on the
command-line being completed.
To avoid this, we first remove the __complete command in such a case so
as to get back to having no sub-commands.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
when `set -o nounset` in Bash,
the warnings of unbound variables will break the bash completion.
use `kubectl` as example:
```sh
$ set -o nounset
$ my-cli <Tab>-bash: BASH_COMP_DEBUG_FILE: unbound variable
$
```
the warning break bash completion without any completion result,
and cause my cursor move to the newline.
Use `${variable:-}` substitution in Bash,
that assign an empty string as default for unbound variables to fix the warnings.
This removes "Lesser" from the GPL-2.0 header template, since that header is meant to be referring to GPL-2.0 and not LGPL-2.0.
Fixes#879
Signed-off-by: Steve Winslow <swinslow@gmail.com>
Pretty major change in behavior, but with modules a change is needed.
Now cobra can initialize and add from within any Go module.
The experience is simplified and streamlined, but requires `go mod init` to happen first.
It's questionable that a default license makes any sense from a legal perspective.
If the tool created the license without the user choosing it, then it may not even be applicable.
Best to let the user choose their license with intent.
Cobra and Viper are great together, but it's not uncommon to use them apart.
New Cobra users don't know better and including Viper by default adds complexity to the skeleton.
When a command has set DisableFlagParsing=true, it means Cobra should
not be handling flags for that command but should let the command
handle them itself. In fact, Cobra normally won't have been told at all
about flags for this command.
Not knowing about the flags of the command also implies that Cobra
cannot perform flag completion as it does not have the necessary info.
This commit still tries to do flag name completion, but when
DisableFlagParsing==true, it continues on so that ValidArgsFunction will
be called; this allows the program to handle completion for its own
flags when DisableFlagParsing==true.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
full diff: https://github.com/cpuguy83/go-md2man/compare/v2.0.0...v2.0.1
- Fix handling multiple definition descriptions
- Fix inline markup causing table cells to split
- Remove escaping tilde character (prevents tildes (`~`) from disappearing).
- Do not escape dash, underscore, and ampersand (prevents ampersands (`&`) from disappearing).
- Ignore unknown HTML tags to prevent noisy warnings
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* Fix flag completion
The flag completion functions should not be stored in the root cmd.
There is no requirement that the root cmd should be the same when
`RegisterFlagCompletionFunc` was called. Storing the flags there does
not work when you add the the flags to your cmd struct before you add the
cmd to the parent/root cmd. The flags can no longer be found in the rigth
place when the completion command is called and thus the flag completion
does not work.
Also #1423 claims that this would be thread safe but we still have a map
which will fail when accessed concurrently. To truly fix this issue use a
RWMutex.
Fixes#1437Fixes#1320
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
* Fix trailing whitespaces in fish comp scripts
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
zsh is now the default on Mac OS, but the $_fpath version of the installation instructions are likely to put the completion in a strange location that the user might not expect (e.g. an oh-my-zsh plugin's function directory). So, since Mac OS seems to (as far as I can tell) provide a stable location, this PR recommends using that path instead.
