Repository navigation
Autocomplete after double dash (--) executing command action. #1993
Description
My urfave/cli version is
v2.27.5
Checklist
- Are you running the latest v2 release? The list of releases is here.
- Did you check the manual for your release? The v2 manual is here
- Did you perform a search about this problem? Here's the GitHub guide about searching.
Dependency Management
- My project is using go modules.
Describe the bug
If Bash completion is enabled, and the user attempts to tab complete after a double dash (--), it will execute the normal command action.
To reproduce
Describe the steps or code required to reproduce the behavior
main.go
package main
import (
"os"
"github.com/urfave/cli/v2"
)
func main() {
app := &cli.App{
Name: "cli_test",
EnableBashCompletion: true,
Action: func(*cli.Context) error {
os.Create("/tmp/cli_test/TestFile.out")
return nil
},
Flags: []cli.Flag{
&cli.BoolFlag{
Name: "verbose",
},
},
}
if err := app.Run(os.Args); err != nil {
panic(err)
}
}using the v2 zsh_autocomplete
Sourcing it as such in my ~/.zshrc
PROG=cli_test source <path to project>/zsh_autocompletemkdir /tmp/cli_test/ && ls /tmp/cli_testDir is empty
Try autocomplete
cli_test --<TAB>
# or
cli_test -- --generate-bash-completion
Check dir
ls /tmp/cli_testTestFile.out is present
Observed behavior
Due to the double dash (--), the --generate-bash-completion flag was treated as an argument, and the command was executed normally. This behavior is INCREDIBLY DANGEROUS as it can cause premature execution of a command, without even pressing enter!
Expected behavior
There are several ways this could be handled.
The ideal solution would be autocompleting the list of long flags, instead of executing the normal command action
Another solution would be preventing the command from being executed and not autocompleting.
Additional context
This problem was introduced by this PR
#1938
I personally disagree with this PR being marked as a bug instead of a feature, and think that this behavior should be toggleable instead of enabled for all cli applications.
This PR did disable bash autocomplete after a double dash, but introduced a much worse issue, which is executing the command normally...
Want to fix this yourself?
If I find time, I may be willing to fix this myself, but I wanted to report this as soon as possible since this bug could cause severe damage in the worse case scenario.
Run go version and paste its output here
go version go1.23.2 darwin/arm64
Run go env and paste its output here
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/aarolieb/Library/Caches/go-build'
GOENV='/Users/aarolieb/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/aarolieb/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/aarolieb/go'
GOPRIVATE=''
GOPROXY='direct'
GOROOT='/opt/homebrew/Cellar/go/1.23.2/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.23.2/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.23.2'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/aarolieb/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOARM64='v8.0'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/Users/aarolieb/Code/Scripts/cli_test/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/_s/694rx7x90x96jkm795h4tk5h0000gr/T/go-build3647699756=/tmp/go-build -gno-record-gcc-switches -fno-common'
Activity
dearchap commentedon Oct 24, 2024
@AaronLieb Yes this is similar to #1916 . I have a fix for this in v3. Let me see if I can backport to v2. Thanks for reporting
AaronLieb commentedon Oct 24, 2024
@dearchap I have confirmed that this issue is still present in v3. Is the v3 fix you mentioned in v3.0.0-alpha9.1?
Edit: Nevermind, I see that its #1987
Not included in the latest v3 release. I'll wait for the next release
dearchap commentedon Oct 24, 2024
No the fix is in PR #1919 .
dearchap commentedon Oct 25, 2024
@AaronLieb Would you be able to test the PR in #1919 to see if it fixes your issue ?
dearchap commentedon Oct 27, 2024
@AaronLieb I looked at v2 and its more complicated to fix there. Not sure if I have the bandwidth to do it for v2. If you end up doing a PR I will be glad to review.
AaronLieb commentedon Oct 27, 2024
@dearchap I'll see if I have some time today to test the v3 fix and push out a v2 PR.
My experience with this library and go experience in general is pretty limited, so if I push out a PR, feel free to give plenty of criticisms.
AaronLieb commentedon Oct 28, 2024
@dearchap the latest v3 alpha version with the v3 fix has an unverified commit and was incorrectly added to go.pkg.dev. The creation date is incorrect, isn't marked as the latest version, and fails the checksum when running
go get github.com/urfave/cli/v3@v3.0.0-alpha10. Please fix the release and let me know once you've done so.I'm working on the v2 fix
dearchap commentedon Oct 28, 2024
@AaronLieb fixed the 3.0.0-alpha10 release issue. Please check
AaronLieb commentedon Oct 28, 2024
@dearchap appears the checksum is still failing when running
go get github.com/urfave/cli/v3@v3.0.0-alpha10dearchap commentedon Oct 28, 2024
@meatballhat can you take a look ?
meatballhat commentedon Oct 30, 2024
If you want to use the latest
v3release, then I recommend:and then
go mod tidyandgo get -uwill get the correct latest in that series (currentlyv3.0.0-alpha9.1) and skip over the bogusv3.0.0-alpha10.Please let us know if this isn't working for you, or if you're unable to use this solution 🙇🏼
10 remaining items
mrueg commentedon Jul 15, 2025
if this is the case, should the PR be reverted?
TimSoethout commentedon Dec 4, 2025
I agree with expecting autocompletion options when typing
--<tab>, potentially including the--itself as valid completion.I can confirm this behavior on bash 5.3 with v3 (v3.6.1) as well.
ab commentedon Dec 5, 2025
This appears to affect the Spacelift
spacectlCLI, which uses v3.4.1. spacelift-io/spacectl#361I'm not familiar with the code here, so take this with a grain of salt, but IMO the approach of appending
--generate-shell-completionseems quite fragile. I might suggest the fix should use a separate subcommand instead of an option, so there's less danger of accidentally executing the underlying command.So when completing after
cli foo --bar, it might run:cli __complete foo --barInstead of the existing
cli foo --bar --generate-shell-completiondearchap commentedon Dec 5, 2025
@ab that's a fantastic suggestion. Unsure why we couldn't have done it this way. I have to dig into the history and investigate
bartekpacia commentedon Dec 5, 2025
@ab @dearchap I believe
__completeis also how Cobra does shell completion (link)dearchap commentedon Dec 6, 2025
@bartekpacia If I make this change would it be considered a breaking change ? If so we would need to release it as v4
mrueg commentedon Mar 10, 2026
@dearchap I assume this could also be non-breaking as an internal option when enabling the shell completion? So you could have the old behaviour in v3 but an additional
EnableBashCompletionAsArg: trueand in v4 you make that one a noop.docs: say what a script generated before this change actually does
fix: never run command action on shell completion past a double dash
chore(deps): update dependency pinact to v5 (#600)
!20094 merge bump-pinact-5.0.0 into main
chore(deps): update dependency aqua:suzuki-shunsuke/pinact to v5 (#5)
chore(deps): update dependency aqua:suzuki-shunsuke/pinact to v5 (#133)
chore(deps): update dependency aqua:suzuki-shunsuke/pinact to v5 (#87)