MinGW: FZF is being interrupted on arrow keys down

[Danand]

• I have read through the manual page (man fzf)
• I have the latest version of fzf
• I have searched through the existing issues

Info

• OS
  • Linux
  • Mac OS X
  • Windows
  • Etc.
• Shell
  • bash
  • zsh
  • fish

Additional details

$ bash --version
GNU bash, version 4.4.23(1)-release (x86_64-pc-msys)

$ git --version
git version 2.37.0.windows.1

$ fzf --version
0.38.0 (352ea07)

$ which fzf
/c/Users/danilov/AppData/Local/Microsoft/WinGet/Packages/junegunn.fzf_Microsoft.Winget.Source_8wekyb3d8bbwe/fzf

Problem

Note: the problem is specific to Git Bash (MinGW) only.
FZF closes after arrow keys down, piping forward an empty result.

Steps to reproduce

1. Open Git Bash (MinGW).
2. Enter:

   git log --oneline | fzf | echo $(cat)

3. Wait for all entries of git log --oneline being loaded.
4. Press arrow key up/down to select entry.
5. Notice that FZF has being interrupted with exit code 0 and empty stdout.

Expected behavior

Being able to navigate through entries with arrow keys.

Actual behavior

FZF shuts down on arrow keys down.

I hope I explained the problem properly!

[ttx99]

@junegunn pls

[junegunn]

I'm not a Windows user so I can't look into the problem. Pull requests are welcome.

[thomashope]

Some more info and a possible workaround for people with this issue. It seams to be related to piping from another command to fzf.

For example, this has the same problem as OP (interrupted by arrow keys)

alias gd="git diff --name-only | fzf --preview 'git diff {-1}'"

But when using an intermediary variable , arrow keys work as normal

function gd() {
        local FILES=$(git diff --name-only)
        echo "$FILES" | fzf --preview 'git diff {-1}'
}

[Danand]

when using an intermediary variable , arrow keys work as normal

Yeah, this is my current workaround too.

[ykhan21]

@Danand, do you still have this issue with the current version of fzf and Windows' git? I remember that this happened to me earlier this year but I cannot replicate it now.

[Danand]

@ykhan21
Hi!
I've installed the latest version for now, but issue is still there.

$ winget update fzf
Found fzf [junegunn.fzf] Version 0.48.1
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://github.com/junegunn/fzf/releases/download/0.48.1/fzf-0.48.1-windows_amd64.zip
  ██████████████████████████████  1.63 MB / 1.63 MB
Successfully verified installer hash
Extracting archive...
Successfully extracted archive
Starting package install...
Command line alias added: "fzf"
Successfully installed

But behaviour has changed a bit. Before FZF was shutting down after arrow keys down during reading stdin (when lines count is changing). Now it's shutting down only after all passed lines being read.

[paulrobello]

Same issue with latest version on win11 x64 running in Windows Terminal Version: 1.19.10573.0 git bash
You can one line the workaround:

FILES=$(ls); echo "$FILES" | fzf; unset FILES

[RossSmithBA]

I am also experiencing this issue. From my crude investigation, the issue appears to manifest:

• in situations when input lines are received over some period of time (~15ms on my machine), and
• at the point where the last line is received.

I came to the 15ms number by trial and error with the following script, run as python test.py <delay-time-in-seconds> | fzf

import sys
import time

delay_time_in_seconds = float(sys.argv[1])

sys.stdout.write(f"First line\n")
sys.stdout.write(f"Second line\n")
sys.stdout.flush()

time.sleep(delay_time_in_seconds)

sys.stdout.write(f"Third line\n")
sys.stdout.flush()

• For delays up to 10ms, I never observe the issue.
• For delays above 20ms, I always observe the issue.
• For large delays (10s, for example), fzf is interactive until the delay expires and the last line is received, at which point I always observe the issue.
  • Even when modifying the script to output more lines, with multiple large delays between them, fzf still behaves correctly until the last line is received.

While this is consistent for the above python script, I have not yet found a way to trigger the issue with a bash script. The following script, for example, does not trigger the issue even with relatively large delays. Run as sh test.sh 10 | fzf:

#!/bin/bash
echo -e "First line\r";
echo -e "Second line\r";
sleep $1;
echo -e "Third line\r";

---

Note that the outputs of these two scripts have been tweaked to result in the same output when piped into od in an attempt to rule out differences in stdout content being the culprit. The output in question (for sh test.sh 1 | od -t c) is:

0000000   F   i   r   s   t       l   i   n   e  \r  \n   S   e   c   o
0000020   n   d       l   i   n   e  \r  \n   T   h   i   r   d       l
0000040   i   n   e  \r  \n
0000045

[ykhan21]

@RossSmithBA, do you see the interrupts if you use winpty fzf instead of fzf?

[RossSmithBA]

@RossSmithBA, do you see the interrupts if you use winpty fzf instead of fzf?

@ykhan21 I was able to run winpty fzf in isolation with no issues, but running fzf in isolation was never an issue for me.

I attempted to pipe in data using my test script (above) but I encountered some errors that I don't yet understand:

python test.py 1 | winpty fzf

stdin is not a tty
Traceback (most recent call last):
  File "C:\--redacted--\test.py", line 9, in <module>
    sys.stdout.flush()
OSError: [Errno 22] Invalid argument
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='cp1252'>
OSError: [Errno 22] Invalid argument

Edit: I have also tried using this build from #3809, but I didn't find any differences in behaviour for my test scenarios.