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

[bartekpacia]

My urfave/cli version is

2.27.1

Checklist

• [x] Are you running the latest v2 release? The list of releases is here.
• [x] Did you check the manual for your release? The v2 manual is here
• [x] Did you perform a search about this problem? Here's the GitHub guide about searching.

Dependency Management

• [x] 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.

https://github.com/urfave/cli/blob/7656c5fb838ca8a6febca43100147d317b544fd3/help.go#L153-L161

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]

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