fzf v0.28.0 incompatiblity with windows bash.exe - Command failed

[ttk]

fzf version 0.28.0 introduced a new change where $SHELL is used instead of cmd.exe by default.

For kubectx for windows, using msys2 bash.exe, the following error occurs:
[Command failed: C:\Programs\Bin\kubectx.exe]

This is because bash.exe doesn't recognize that path, but cmd.exe does. This problem doesn't occur in powershell, or cmd.exe.

The workaround is to set the env var SHELL=cmd prior to running kubectx. I setup an alias for this:

alias kx='SHELL=cmd kubectx'

I'm wondering maybe this env variable should be automatically set via kubectx if it detects it's running in windows?

[ahmetb]

That's a weird issue. Mostly because we (and other tools) trust fzf to do the right thing.

Furthermore, we're planning to allow customizing the picker tool to something other than "fzf", and such customizations wouldn’t carry to similar other tools like "sk" well.

Is there a reason why $SHELL is already not set properly (like it is on Linux/Mac) by your msys2? Can't you just set it on your .bashrc?

Since this is a rather subtle issue, I am inclined to not fix it in this tool but rather expect the environment to do right thing.

If msys2 can't render properly and needs SHELL=cmd, I think that's not kubectx's issue. Maybe fzf or msys bash should fix it. Sorry if I misinterpreted, feel free to correct me.

[ttk]

Yeah, it's a strange one. My shell env var is properly set to SHELL=/usr/bin/bash, so it doesn't make sense to change that in my .bashrc file. The problem occurs because kubectx sees the command as the native windows path C:\Programs\Bin\kubectx.exe and passes that on to fzf via FZF_DEFAULT_COMMAND=C:\Programs\Bin\kubectx.exe, but then fzf runs it in the bash shell, as per the SHELL env var, which doesn't work.

So basically kubectx needs to give a hint to fzf to run the command without a shell (ideally), but apparently isn't supported a far as I can tell from the fzf source code, which I think is the crux of the problem.

Is there any reason why fzf needs to run kubectx in the context of a shell? Perhaps the fzf project needs to add a new environment variable such as FZF_DISABLE_SHELL? Another option is to simply unset SHELL environment variable prior to running fzf, and fzf will simply default back to the default shell on each system, which I think should work?

msys2 bash.exe:
SHELL="" FZF_DEFAULT_COMMAND=C:\\Programs\\Bin\\kubectx.exe fzf works
FZF_DEFAULT_COMMAND=C:\\Programs\\Bin\\kubectx.exe fzf does not work

[ahmetb]

Is there any reason why fzf needs to run kubectx in the context of a shell?

We don't. We directly run it:

kubectx/cmd/kubectx/fzf.go

Line 95 in 617e4f0

cmd := exec.Command("fzf", "--ansi", "--no-preview")

However since you're on mingw/cygwin environments, it is very likely that these things trap syscalls and manipulate them.

I'm inclined to not fix this as it might further cause compat issues in edge cases (admittedly this itself is definitely a rare scenario I haven't heard so far).

[mloskot]

I'm using Git Bash from Git for Windows 2.40.0

$ echo $SHELL
/usr/bin/bash

and I found that the original workaround suggested by @ttk does not work for me, so instead of this

alias kx='SHELL=cmd kubectx'

the following alias works

alias kx='SHELL= kubectx'

---

kubectx --version
0.9.4
fzf --version
0.39.0 (2023040)

---

By the way, this workaround solves #382