Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shell completions are broken when login shell is different than currently active shell #1884

Open
4 tasks done
bartekpacia opened this issue Apr 8, 2024 · 1 comment
Open
4 tasks done
Labels
area/v2 relates to / is being considered for v2 area/v3 relates to / is being considered for v3 kind/bug describes or fixes a bug

Comments

@bartekpacia
Copy link
Member

bartekpacia commented Apr 8, 2024

My urfave/cli version is

2.27.1

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

Shell completions to show are determined by looking at contents of the $SHELL environment variable, which isn't a reliable way to do this because the current login shell isn't always the current active shell.

cli/help.go

Lines 153 to 161 in 7656c5f

if strings.HasSuffix(os.Getenv("SHELL"), "zsh") {
for _, name := range command.Names() {
_, _ = fmt.Fprintf(writer, "%s:%s\n", name, command.Usage)
}
} else {
for _, name := range command.Names() {
_, _ = fmt.Fprintf(writer, "%s\n", name)
}
}

To reproduce

Here's my simple CLI app with shell completions.

Observed behavior

My shell is Zsh, and when I run:

$ fhome [tab]
config     -- Manage system configuration
event      -- Manage events
help    h  -- Shows a list of commands or help for one command
object  o  -- Manage objects

but when I run Bash first and then trigger completions, my CLI tools still outputs Zsh-style completions:

$ bash
bash-5.2$ fhome
a              commands       configuration  events         h:Shows        help:Shows     o:Manage       objects        one            system
command        config:Manage  event:Manage   for            help           list           object:Manage  of             or

Expected behavior

I expect shell completion to work for the current active shell, so this bug won't happen.

Additional context

  • Maybe we can take a look at how Cobra does it.
  • This also occurs in v3 alpha, please add appropriate labels

Want to fix this yourself?

Sure!

Run go version and paste its output here

$ go version
go version go1.22.2 darwin/arm64

Run go env and paste its output here

$ go env
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/bartek/Library/Caches/go-build'
GOENV='/Users/bartek/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/bartek/.cache/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/bartek/.cache/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.22.2/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.22.2/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.2'
GCCGO='gccgo'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/Users/bartek/projects/fhome/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/r6/5z0bypqn4cb8p369zlrfhw3c0000gn/T/go-build3283617553=/tmp/go-build -gno-record-gcc-switches -fno-common'
@bartekpacia bartekpacia added area/v2 relates to / is being considered for v2 kind/bug describes or fixes a bug status/triage maintainers still need to look into this labels Apr 8, 2024
@bartekpacia bartekpacia changed the title your bug title goes here Shell completions are broken when login shell is different than currently active shell Apr 9, 2024
@dearchap dearchap added the area/v3 relates to / is being considered for v3 label Apr 16, 2024
@meatballhat meatballhat removed the status/triage maintainers still need to look into this label May 6, 2024
@bartekpacia
Copy link
Member Author

This is not actually fixed since the fix introduced a regression and had to be reverted in #1997.

@bartekpacia bartekpacia reopened this Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/v2 relates to / is being considered for v2 area/v3 relates to / is being considered for v3 kind/bug describes or fixes a bug
Projects
None yet
Development

No branches or pull requests

3 participants