Fzf: [Ubuntu] --preview error : Failed to read /dev/tty

[erch]

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

When I use --preview I got the error message: Failed to read /dev/tty

$ echo "hello" | fzf
hello
$ echo "hello" | fzf --preview 'echo {}'
Failed to read /dev/tty
$ echo $TERM
xterm-256color
$ tty
/dev/pts/6
$ fzf --version
0.17.5 (b46227d)
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.1 LTS
Release:    18.04
Codename:   bionic

[winvicta]

I have just run into the same problem. The problem occurred just after a system update. System is ubuntu 18.04 LTS. Before the system update, everything worked flawlessly.
Symptoms:

1. When entering ALT-C (default binding), system responded by printing the message "Failed to read /dev/tty".
2. When entering /dev/tty, system responded by printing "bash: /dev/tty: Permission denied"
3. When entering tty, system responded by printing "/dev/pts/1"

"sudo chmod 777 /dev/tty" won't make a difference. uninstalling/reinstalling won't make a difference.

The other commands CTRL-R and CTRL-T work without any problems.

Any help will be appreciated. Thanks.

[bartels]

I'm seeing this too. It appears to have started after an Ubuntu 18.04 kernel update to 4.15.0-44. Booting back into the previous 4.15.0-43 kernel and the error does not happen.

[ianchanning]

• fzf v0.17.5 (also fails with 0.17.4 but upgraded to rule anything else out)
• Ubuntu 18.04
• uname -a: Linux ICT0115123 4.15.0-44-generic #47-Ubuntu SMP Mon Jan 14 11:26:59 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

I'm hitting this problem too, it breaks the fzf.vim plugin. I get the following error in Vim:

Error running 'fzf'  '-m' '--prompt' '~/' --expect=ctrl-v,ctrl-x,ctrl-t --height=19 > /tmp/vHnZunZ/2

If I run the equivalent command I get:

channi16@ICT0115123:~$ fzf -m --prompt ~/ --expect=ctrl-v,ctrl-x,ctrl-t --height=19 > /tmp/vHnZunZ
Failed to read /dev/tty

However just running fzf at the command line typically works - although this will also sometimes fail with Failed to read /dev/tty

[ianchanning]

I tried to track this down a bit more, it appears to be the innocuous --height parameter that causes the error:

channi16@ICT0115123:~$ fzf -m --prompt ~/ --expect=ctrl-v,ctrl-x,ctrl-t --height=14 > /tmp/vvHpkEQ
Failed to read /dev/tty
^[[3;1Rchanni16@ICT0115123:~$ fzf -m --prompt ~/
channi16@ICT0115123:~$ fzf -m --prompt ~/ --expect=ctrl-v,ctrl-x,ctrl-t
channi16@ICT0115123:~$ fzf -m --prompt ~/ --expect=ctrl-v,ctrl-x,ctrl-t --height=14
Failed to read /dev/tty
^[[7;1Rchanni16@ICT0115123:~$ ;1R

So:

1. fzf -m --prompt ~/ works
2. fzf -m --prompt ~/ --expect=ctrl-v,ctrl-x,ctrl-t works
3. fzf -m --prompt ~/ --expect=ctrl-v,ctrl-x,ctrl-t --height=14 fails

And it's not in combination with any other argument:

channi16@ICT0115123:~$ fzf --height=14
Failed to read /dev/tty
^[[48;1Rchanni16@ICT0115123:~$ ;1R

[ianchanning]

I managed to get fzf working in Vim (although it caused a core dump twice before it worked) by changing the display of fzf to be on the left rather than the bottom (my guess was this would stop using the --height param in the command) based on the README-VIM examples:

let g:fzf_layout = { 'left': '~70%' }

Actually I do still sometimes get an error:

Error running 'fzf'  '-m' '--prompt' '~/' --expect=ctrl-v,ctrl-x,ctrl-t --no-height > /tmp/vWogPww/11

But then running fzf -m --prompt ~/ --expect=ctrl-v,ctrl-x,ctrl-t --no-height on the command line works and after checking that it works in the command line restarting Vim means that it works again.

[tanc]

@ianchanning that change to fzf_layout doesn't seem to help in my set up, it opens on the side but still throws the error. It may be because I'm running tmux.

[tanc]

Confirmed that booting Ubuntu kernel 4.15.0-43 allows fzf to work properly. For now have uninstalled 4.15.0-44 and am booting previous kernel.

[ianchanning]

@tanc I'm not using tmux, so it could lie with that. See if you can run the same command outside Vim - I find that it will sometimes crash, but I can also get it to work with the fzf_layout change where as before calling FZF from within Vim failed all the time.

[tanc]

As a working fzf in vim is such an important part of my daily work I ended up rolling back the kernel

[ianchanning]

The other option that seems to work for me is to use neovim instead. So it could be an issue around the handling of :terminal in Vim vs neovim.

[tanc]

Interesting, I'm using neovim and was seeing the problem

[bartels]

A likely culprit: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813873

[lungtendo]

I'm seeing the same problem after upgrading to Linux kernel 4.15.0-44 on Ubuntu 18.04. The problem crops up randomly, it works most of the time.

[taranjlu]

I'm new to using fzf but I believe I am running into the same issue on Linux Mint with kernel 4.18.0-14. As mentioned above, the problem appears to happen somewhat randomly. In gnome terminal, it seems to happen consistently when run from the command line, although, Ctrl+R works correctly. When using Alacritty, I also get the same error, but then it seems to start working after using Ctrl+R once.

Edit: I have fzf installed via Linuxbrew.

[lungtendo]

Kernel version updated to 4.15.0-45 but that didn't help. Updated FZF to the latest. Still seeing the error randomly.

[vhakulinen]

After doing some research, every time I get Failed to read /dev/tty, this returns syscall.EAGAIN. ~This probably means that the operation needs to be tried again: https://stackoverflow.com/questions/4058368/what-does-eagain-mean~

[ianchanning]

@vhakulinen this is a benefit of using neovim instead of vim, with neovim when FZF :Files fails you can retry and after a couple of times FZF will work. However in vim it causes vim to crash entirely.

[vhakulinen]

:Files is not working at all for me since I have g:fzf_layout={'up': '20%'}. If I pump it to ~70% it works randomly, but with 20% it doesn't work at all.

[bartels]

@vhakulinen your findings are consistent with the ubuntu kernel bug linked above. It mentions:

a rather serious regression where userspace applications reading
from stdin can receive EAGAIN when they should not

I see the bug has been marked Fix Committed but I think it may not have been released yet. I find Launchpad pretty confusing when it comes to figuring this kind of thing out. I guess we'll see with the next kernel update.

[stephentalley]

With some trial and error, I've found that this can reliably reproduce the issue:

bash -c "sleep 1; bash -c 'echo hello'" | fzf

[kthibodeaux]

For anyone who is as impatient to have this working as I was: I was able to use https://mintguide.org/tools/691-ukuu-ubuntu-kernel-upgrade-utility.html to install a newer kernel and fix this issue.

[vhakulinen]

@bartels I _think_ they have other status for "Fix released".

[ilija139]

@vhakulinen You are right: https://blog.launchpad.net/general/of-bugs-and-statuses

[ploth]

with neovim when FZF :Files fails you can retry and after a couple of times FZF will work.

Can confirm, works after retrying multiple times. I'm on 4.15.0-44-generic.

[ianchanning]

With kernal 4.15.0-45 the problem appears to be worse for me. Simply running fzf in the terminal or in vim/neovim fails now. I had one successful attempt in about 20.

[jerdna-regeiz]

Simple fix is to read tty again. Maybe retries do not have to be normally, but in this case it solves the problem without going for an older kernel :) (see #1495)

[stephentalley]

I had to bump the retries to 10 in @jerdna-regeiz's workaround to make it consistently work on 4.15.0-45-generic.

Probably not something that should be integrated into junegunn:master, but a useful workaround until Ubuntu can push out an updated kernel.

[ianchanning]

I've no idea if this will work for other people, but I think I've found a workaround (plus it's a good solution in general anyway).

My usage of FZF with Ctrl + R has always worked fine - so it's not FZF that's necessarily the problem but the command it's calling. Today randomly I switched to using fd (https://github.com/sharkdp/fd) for my FZF search and FZF now seems to happily work even on 4.15.0-45-generic.

Once you've installed fd you can try putting this in your .bashrc, restart your terminal and see if fzf works again:

    export FZF_DEFAULT_COMMAND='fd --hidden --exclude ".git" .';
    export FZF_CTRL_T_COMMAND="$FZF_DEFAULT_COMMAND"

[ianchanning]

Update: This has been working for me the whole day so far.

The bash -c "sleep 1; bash -c 'echo hello'" | fzf will still give an error, but that seems unrelated. Perhaps that gave an error before this bug occurred as well.

[andrewrech]

@ianchanning I see this issue with fd also (4.15.0-1032-aws)

However @jerdna-regeiz solution worked for me also, but like others, I needed 10 retries: linux_amd_64 binary.

[nickgronow]

I am getting the error as well on Ubuntu 18.10.

uname -a
Linux nick-xps-9370 4.18.0-14-generic #15-Ubuntu SMP Mon Jan 14 09:01:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Here is my error:

Error running 'fzf'  '-m' '--prompt' '~/' --expect=ctrl-v,ctrl-s,ctrl-t --no-height > /tmp/nvim5QXxS8/17

Mine doesn't complain specifically about the preview error (removed it for now to see if that fixes it, which it didn't, but did drop the rate of occurrence).

[pkmital]

Not that I know what I'm doing but sudo chmod 660 /dev/tty solved what appeared to be a similar problem on my Ubuntu 16.04 4.15.0-1027-gcp machine.

[yarres]

Chmod on /dev/tty worked for me too.

[anovix]

sudo chmod 660 /dev/tty works for me too, but then ssh does not work for me :laughing:

ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Permission denied, please try again.

When I change it back to 666 (as it was), ssh works but fzf does not.

[marcinpraczko]

I have the same problem, FZF stopped working on ubuntu after last patching. Simple fzf is not working - `fzf --prefview {}`` - not working as well.

Linux 4.15.0-45-generic #48~16.04.1-Ubuntu SMP Tue Jan 29 18:03:48 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
"Ubuntu 16.04.5 LTS"

[jinhkim]

Doing sudo chmod 600 /dev/tty also breaks tig, which apparently expects 666 as the file permission.

[emont01]

For those using Ubuntu a related fix has being released in kernel version 4.18.0-15.16, hopefully that will resolve this problem

http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_4.18.0-15.16/changelog

linux (4.18.0-15.16) cosmic; urgency=medium

  * Userspace break as a result of missing patch backport (LP: #1813873)
    - tty: Don't hold ldisc lock in tty_reopen() if ldisc present

 -- Stefan Bader <[email protected]>  Thu, 07 Feb 2019 11:24:34 +0100

[lancekrogers]

For those using Ubuntu a related fix has being released in kernel version 4.18.0-15.16, hopefully that will resolve this problem

http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_4.18.0-15.16/changelog

linux (4.18.0-15.16) cosmic; urgency=medium

  * Userspace break as a result of missing patch backport (LP: #1813873)
    - tty: Don't hold ldisc lock in tty_reopen() if ldisc present

 -- Stefan Bader <[email protected]>  Thu, 07 Feb 2019 11:24:34 +0100

Just updated ubuntu 18.04 to kernal 4.18.20 and fzf now works

[mlopezgva]

A simple workaround until the kernel correction: disable the "content preview" (head {} whatever).
At least worked for me, both in the cmdline (bash) and inside vim.

At least we can keep using it.

[shuhaowu]

Installing the hardware enablement stack for 18.04 seems to fix the issue. The packages are: linux-image-generic-hwe-18.04 linux-headers-generic-hwe-18.04

[acc248]

Was experiencing the issue in both nvim and using the cmdline (bash -c "sleep 1; bash -c 'echo hello'" | fzf) on kernel 4.15
I installed @shuhaowu packages, restarted, and both nvm and cmdline work. uname-r is showing 4.18.0-15-generic which seems consistent with updating the kernel directly via @emont01 solution.

[in3rsha]

I was running 4.15.0-45-generic and fzf was working with Bash, but was getting this error with Fish:

Failed to read /dev/tty

However, fzf is now working after following @shuhaowu's advice and installing:

sudo apt install linux-image-generic-hwe-18.04 linux-headers-generic-hwe-18.04

Although I'm not quite sure what this does, apart from possibly changing my kernel to a completely different version.

$ uname -r
4.18.0-15-generic

[PovelikinRostislav]

The same error is on Ubuntu 16.04.

$ uname -r
4.15.0-45-generic

[reefloretto]

Also getting this error on Ubuntu 16.04 (in a bash shell):

> lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.5 LTS
Release:    16.04
Codename: xenial
> uname -r
4.15.0-45-generic

For some reason I _don't_ get the error in a tmux session.

[aapit]

The solution / workaround by @shuhaowu works for me too (after a reboot) in tmux under Ubuntu 18.04 - upgraded to kernel 4.18.0-15-generic. Did the trick for both inside of Vim and on Bash 4.4.19.

[junegunn]

Hey Ubuntu users (16.04 and 18.04), you can help Ubuntu team release the fix. See:

• 16.04: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813873/comments/11
  
  
  
  • Verification complete
  
  
• 18.04: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813873/comments/27
  
  
  
  • Verification complete
  
  

[nickgronow]

Would that apply for cosmic as well? I would participant if I could get that proposed change.

[junegunn]

@nickgronow It appears that the fix was already released for Cosmic. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813873/comments/21

[JiHyeongSeo]

Installing the hardware enablement stack for 18.04 seems to fix the issue. The packages are: linux-image-generic-hwe-18.04 linux-headers-generic-hwe-18.04

nice. it works!

[Karmenzind]

fixed by

apt install linux-image-generic-hwe-18.04 linux-headers-generic-hwe-18.04
apt update -y && apt upgrade -y
reboot

[diegolealco]

From Ubuntu's documentation LTS Enablement Stacks, the recommended way to install a hardware enablement stack is as follows:

sudo apt install --install-recommends linux-generic-hwe-18.04

I am not convinced that this is a proper solution. Either the kernel developers introduced a necessary change, a bug with an update, or a piece of software (fzf in this case) is using a feature in perhaps the wrong way; remember that kernel developers are very anal when it comes to not breaking userspace.

[ianchanning]

@nzxcr no the hardware enablement isn't a proper solution. There's a fix in the kernel, it just needs verification on 18.04. See @junegunn 's comment. But if it's not verified by testers by Monday they'll drop the bug fix.

[ianchanning]

I've confirmed that:

1. If I remove my use of fd fix then I get the error
2. If I turn on proposed releases (in Software & Updates > Developer Options), do an update to 4.15.0-46-generic and then restart I no longer get the error

uname -a
Linux ICT0115123 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

I've also just spotted that in @junegunn 's comment the status of the bug has been updated to verified. :tada:

[nickgronow]

Updating to the latest on Ubuntu 18.10 fixed it.

[mrvon]

On ubuntu 16.04, I downgrade to linux-image-4.4.0-141 sloved this problem.

sudo apt remove linux-image-4.4.0-142-generic linux-headers-4.4.0-142

[marcinpraczko]

Is there any fix on ubuntu 16.04 for upgrade kernel - not downgrade?

[ianchanning]

@marcinpraczko Yes - see @junegunn 's comment. It'll probably still be in pre-release. You can turn on proposed releases in the Software and Updates > Developer Options (tab)

[moonwater]

I have the same issue on ubuntu
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Release: 18.04
Codename: bionic

$ uname -r
4.15.0-45-generic

I got "Failed to read /dev/tty" in bash.
and then I install a shell of fish to run fzf, it works for the first time. and it failed with the same error message for the second time.

I don't know why, everything works fine in tmux.

And I think it might cause more problem using specific version of kernel by:

sudo apt install linux-image-generic-hwe-18.04 linux-headers-generic-hwe-18.04

[rtucek]

I upgraded to the recently released kernel 4.15.0-46-generic on Ubuntu 18.04 and approve that the regression has been fixed.

edit:
As a sidenote - I haven't used the HWE kernel stack just patiently waited for the fix to be released.

[pgebheim]

I as well can confirm that upgrading to 4.15.0-46 fixes this regression.

[daveyarwood]

I just upgraded my Linux kernel to 4.15.0-46 and the vim-fzf issue is fixed for me, _but_ only if I run vim with SHELL set to bash (i.e. SHELL=bash vim path/to/file.txt)

I use fish shell, so my SHELL is ordinarily set to /usr/bin/fish.

When I run vim without setting SHELL in bash, I still see the "Failed to read /dev/tty" message when I run :FZF, and I get the following error message:

Error running ( /usr/bin/fish '/tmp/user/1000/nvim8K9mNu/11' )|'/home/dave/.fzf/bin/fzf'  '--multi' '--prompt' '~/.dotfiles/' --expect=ctrl-v,ctrl-x,ctrl-t --no-height > /tmp/user/1000/nvim8K9mNu/10

Is there some way that I can have fzf use bash instead of fish? Some configuration for vim-fzf, maybe? As a workaround, I could alter my vim alias to be SHELL=bash nvim, but that's a bit clunky.

EDIT: Worth noting: I have set shell=bash in my vimrc, so perhaps vim-fzf could recognize that and use bash instead of fish?

[dnmfarrell]

I was bitten by this on 14.04 4.4.0-142. Downgrading to 4.4.0-141 resolved the issue

[butla]

Was resolved with patches to the kernel of 18.04. The only version still waiting for the patch is Xenial (looking at the bug report).

Actually, shouldn't this issue be closed? It's just waiting on that Ubuntu fix to go in right now.

[daveyarwood]

I'm still seeing this issue appear sporadically for me. It seems to happen if I use vim-fzf twice in quick succession, i.e.

1. Run :FZF, fuzzy find my way to a file, select the file.
2. Immediately run :FZF again.

I'm on Ubuntu 16.04, FWIW.

[piroux]

For Ubuntu 14.04 with a 4.4.0 Kernel, the package 4.4.0-143.169, released last Friday, fixes the bug.

This bug was fixed in the package linux - 4.4.0-143.169
linux (4.4.0-143.169) xenial; urgency=medium

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814647

[njohnson7]

still have same problem on Ubuntu kernel 5.3.0-20-generic and neovim v0.5.0-dev

[PhilippOrtnerUp2Go]

I also still have it.
uname -a
5.3.11-050311-generic SMP Tue Nov 12 21:37:23 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[75re]

I also still have it.
$ uname -a
Linux jimmy-OptiPlex-3020 4.15.0-45-generic #48~16.04.1-Ubuntu SMP Tue Jan 29 18:03:48 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[ofrades]

I have the same issue with Ubuntu 20.04 LTS

Error running cd '/home/ofrades' && cat '/tmp/vp6RsJV/12'LINES=70 COLUMNS=240 'home/ofrades/.vim/plugged/fzf/bin/fzf-tmux' -p90%,60% -- '--color=bg+:236,bg:237,boders:240,spinner:108,hl:65,fg:252,header:65,info:143,pointer:161,marker:168,fg+:252,prompt:110,hl+:108' --ansi --expect ctrl-x --tiebreak+index --header-lines 1 -x --prompt "Commands> " -2,3,2..3 -d > /tmp/vp6RsJV/11

Update: I actually have it working
By updating

if exists('$TMUX')
  let g:fzf_layout = { 'tmux': '-p90%,60%' }
else
  let g:fzf_layout = { 'window': { 'width': 0.9, 'height': 0.6 } }
endif

to only this line
let g:fzf_layout = { 'window': { 'width': 0.9, 'height': 0.6 } }

[junegunn]

You need tmux 3.2 or above to use popups.