FZF appears to swallow key presses when used with less on Git Bash with ZSH on Windows

[marovira]

Checklist

• I have read through the manual page (man fzf)
• I have searched through the existing issues
• For bug reports, I have checked if the bug is reproducible in the latest version of fzf

Output of fzf --version

0.60.0 (3347d61)

OS

• Linux
• macOS
• Windows
• Etc.

Shell

• bash
• zsh
• fish

Problem / Steps to reproduce

Steps

1. Open a terminal using either Git Bash or ZSH within Git Bash.
2. Enter echo "<file>" | fzf --bind="enter:execute(less {})" where <file> is any regular file.
3. The fzf prompt appears with the given file. Press enter to select it.

4. The less prompt opens. Now try to press any key (j, k, etc) and see that nothing happens. Pressing Esc, <C-d>, <C-x> or <C-c> also have no effect. The only way to return to ZSH is to manually kill the less process.

Notes

• If only regular keys are pressed (i.e. keys without any modifiers) and the less process is killed, the pressed keys will appear in fzf's prompt, which seems to indicate that fzf is somehow swallowing the key presses that should've gone to less. In the example below, I pressed kl before killing the less process. See that the pressed keys appear in fzf's prompt.

• The issue is exclusive to Windows, Linux does not present this problem.
• The issue is reproducible in either Git Bash or Git Bash + ZSH.

[marovira]

The issue was first noticed in forgit and reported at wfxr/forgit#423. After diagnosing, it was determined that the problem is with fzf itself.

[marovira]

@junegunn I'm not overly familiar with debugging shell code, but I'm willing to help debug this if you have any ideas of what could be going on.

[junegunn]

I have no idea. One thing I'd like to check is if fzf is using winpty on your environment.

fzf/src/winpty_windows.go

Lines 14 to 44 in 3ba82b6

	func isMintty345() bool {
	return util.CompareVersions(os.Getenv("TERM_PROGRAM_VERSION"), "3.4.5") >= 0
	}
	func needWinpty(opts *Options) bool {
	if os.Getenv("TERM_PROGRAM") != "mintty" {
	return false
	}
	if isMintty345() {
	/*
	See: https://github.com/junegunn/fzf/issues/3809
	"MSYS=enable_pcon" allows fzf to run properly on mintty 3.4.5 or later.
	*/
	if strings.Contains(os.Getenv("MSYS"), "enable_pcon") {
	return false
	}
	// Setting the environment variable here unfortunately doesn't help,
	// so we need to start a child process with "MSYS=enable_pcon"
	// os.Setenv("MSYS", "enable_pcon")
	return true
	}
	if opts.NoWinpty {
	return false
	}
	if _, err := exec.LookPath("winpty"); err != nil {
	return false
	}
	return true
	}

• What is the value of $TERM_PROGRAM_VERSION?
• And $TERM_PROGRAM?
• Does setting MSYS=enable_pcon make any difference?

[marovira]

For both Git bash with ZSH and vanilla Git bash:

• Output of $TERM_PROGRAM_VERSION: none. The variable isn't set
• Output of $TERM_PROGRAM: none. The variable isn't set
• Using export MSYS=enable_pcon doesn't change the behaviour.

[junegunn]

I started a Windows Server 2025 instance on EC2, installed the latest Git bash, downloaded fzf 0.60.2, and tested it.

So here's what I've found.

seq 1000 > test

# less opens and closes immediately
echo test | ./fzf --bind 'enter:execute:less {}'

# But with the redirection, less works
# * NOTE: On non-Windows systems, this is not required
#   https://github.com/junegunn/fzf/commit/3dee8778d073199e0fe1e186e54f7eabc2fdef43
echo test | ./fzf --bind 'enter:execute:less {} > /dev/tty'

# However, when using a non-fullscreen renderer, less becomes unresponsive as reported
echo test | ./fzf --bind 'enter:execute:less {} > /dev/tty' --height 50%

So the issue has to do with the LightRenderer implementation for Windows.

https://github.com/junegunn/fzf/blob/master/src/tui/light_windows.go

[junegunn]

This seems to be the culprit.

fzf/src/tui/light_windows.go

Lines 70 to 84 in 21ce700

	// the following allows for non-blocking IO.
	// syscall.SetNonblock() is a NOOP under Windows.
	go func() {
	fd := int(r.inHandle)
	b := make([]byte, 1)
	for !r.closed.Get() {
	// HACK: if run from PSReadline, something resets ConsoleMode to remove ENABLE_VIRTUAL_TERMINAL_INPUT.
	_ = windows.SetConsoleMode(windows.Handle(r.inHandle), consoleFlagsInput)
	_, err := util.Read(fd, b)
	if err == nil {
	r.ttyinChannel <- b[0]
	}
	}
	}()

[junegunn]

Can you test 8916cbc?

Attaching the amd64 binary. fzf.exe.zip

It still has a problem of consuming a key for execute program, but it's not trivial to properly fix it.

[marovira]

This pretty much solves it. The first key press is still being swallowed, but subsequent key presses work as expected. With the repro I gave for this issue, if I want to exit less I need to press q twice. That said, this is significantly better than before as I can use commands invoked through fzf! Thanks for the quick turnaround!

[junegunn]

Thanks for the confirmation. I'll release a new patch version with the (partial) fix and keep this open until we find the perfect solution.

Some pointers:

• https://github.com/muesli/cancelreader/blob/main/cancelreader_windows.go