fzf doesn't accept input

[tw4452852]

• Category
  • fzf binary
  • fzf-tmux script
  • Key bindings
  • Completion
  • Vim
  • Neovim
  • Etc.
• OS
  • Linux
  • Mac OS X
  • Windows
  • Windows Subsystem for Linux
  • Etc.
• Shell
  • bash
  • zsh
  • fish

Today I just upgrade the fzf to 2d61691 and run fzf on current directory, but it doesn't accept any input..

I just bisect it, found that this commit is the culprit: 6ccc12c,
Any help? Thanks.

[junegunn]

Please provide more details about your environment: OS distro, terminal emulator, fzf --version, etc. Do you have the same issue when you do fzf --height 30%?

6ccc12c was made in January, and no one has reported this issue so far. Hmm.

[tw4452852]

@junegunn

> fzf --version
0.16.7
> uname -a
Linux totorow 4.4.6-gentoo #1 SMP Wed Apr 26 15:08:41 CST 2017 x86_64 Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz GenuineIntel GNU/Linux

And I use urxvt, its version is: rxvt-unicode (urxvt) v9.21 - released: 2014-12-31

Do you have the same issue when you do fzf --height 30%?

Yes, it doesn't work as expected, it just hang:

> fzf --height 30%

And ctrl-c doesn't work, I have to kill it in another terminal.

Do you need any other information?

[junegunn]

it just hang

1. So you see nothing? Same issue with echo foo | fzf --height 30%?

2. Does the following command report the position of your cursor?

echo -e "\x1b[6n"

3. And can you test it with a different terminal emulator? (I'm not saying that urxvt is not supported. I can't reproduce the problem with urxvt installed on my mac.)

[tw4452852]

So you see nothing? Same issue with echo foo | fzf --height 30%?

Yes.

Does the following command report the position of your cursor?

/home/tw/golib/src/github.com/junegunn/fzf [tw@totorow] 
> echo -e "\x1b[6n"
"
/home/tw/golib/src/github.com/junegunn/fzf [tw@totorow] 
> ;1R;2R

And can you test it with a different terminal emulator?

I test it in xterm, same issue, weird...

Also, I test in bash, also not work...

[junegunn]

That's strange. Can you check what's going on under the hood using strace?

FZF_DEFAULT_COMMAND='seq 1000000' strace -o /tmp/o -f fzf

[tw4452852]

trace.txt

[junegunn]

Trace shows that fzf successfully started child process (seq) and it worked as expected (read(5, ...) and close(5)). fzf is also reading your keyboard input (read(3, ...)). write(2, ...) indicates that it's rendering the finder on STDERR, which is also expected. I don't see why it's not rendered on your screen.

You seem to be using fzf binary built from source. I'm not sure if it'll make any difference, but can you test again with the prebuilt binary below?

https://github.com/junegunn/fzf-bin/releases/download/0.16.7/fzf-0.16.7-linux_amd64.tgz

[tw4452852]

Ah, the prebuilt binary works !
I just go get -u github.com/junegunn/fzf/src/fzf, is there any difference?

> go version
go version devel +3a342af Fri Apr 28 00:03:30 2017 +0000 linux/amd64

[junegunn]

I have no idea. I used go version go1.8.1 to build the binaries.

[tw4452852]

I have just bisected go version locally, this commit caused the issue.

[junegunn]

Thanks, I'll take note of that.