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

erch · 2019-01-29T09:31:01Z

winvicta · 2019-01-29T14:48:12Z

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:

When entering ALT-C (default binding), system responded by printing the message "Failed to read /dev/tty".
When entering /dev/tty, system responded by printing "bash: /dev/tty: Permission denied"
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 · 2019-01-29T21:46:27Z

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 · 2019-01-30T07:59:55Z

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 · 2019-01-30T08:06:01Z

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:

fzf -m --prompt ~/ works
fzf -m --prompt ~/ --expect=ctrl-v,ctrl-x,ctrl-t works
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 · 2019-01-30T08:28:29Z

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 · 2019-01-30T11:45:06Z

@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 · 2019-01-30T13:04:44Z

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 · 2019-01-30T14:05:59Z

@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 · 2019-01-30T14:17:44Z

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

ianchanning · 2019-01-30T14:45:04Z

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 · 2019-01-30T15:23:40Z

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

bartels · 2019-01-30T20:13:25Z

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

lungtendo · 2019-01-31T04:48:59Z

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 · 2019-01-31T09:30:39Z

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.

junegunn/fzf#1486 (comment)

lungtendo · 2019-02-01T06:34:47Z

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

vhakulinen · 2019-02-02T11:29:57Z

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 · 2019-02-02T14:56:08Z

@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 · 2019-02-02T15:28:57Z

: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 · 2019-02-02T21:59:30Z

@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 · 2019-02-02T22:31:18Z

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 · 2019-02-02T22:41:00Z

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 · 2019-02-03T11:09:17Z

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

nickgronow · 2019-02-13T20:27:47Z

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

junegunn · 2019-02-14T02:04:10Z

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

JiHyeongSeo · 2019-02-14T13:42:26Z

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 · 2019-02-15T02:34:31Z

fixed by

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

diegolealco · 2019-02-15T19:43:53Z

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 · 2019-02-16T15:45:47Z

@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 · 2019-02-18T10:38:28Z

I've confirmed that:

If I remove my use of fd fix then I get the error
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. 🎉

nickgronow · 2019-02-18T13:41:01Z

Updating to the latest on Ubuntu 18.10 fixed it.

mrvon · 2019-02-19T09:50:46Z

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 · 2019-02-21T06:54:51Z

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

ianchanning · 2019-02-21T07:31:15Z

@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 · 2019-03-01T02:07:51Z

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 · 2019-03-05T23:45:43Z

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 · 2019-03-06T20:10:51Z

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

daveyarwood · 2019-03-07T14:31:45Z

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 · 2019-03-13T13:55:46Z

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

butla · 2019-03-14T18:20:34Z

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 · 2019-03-14T18:50:04Z

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.

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

I'm on Ubuntu 16.04, FWIW.

piroux · 2019-03-17T23:40:55Z

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 · 2019-11-14T00:20:37Z

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

PhilippOrtnerUp2Go · 2019-11-20T09:38:40Z

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 · 2020-03-24T06:52:23Z

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 · 2020-07-19T16:19:46Z

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 · 2020-07-21T05:38:30Z

You need tmux 3.2 or above to use popups.

shaheinm mentioned this issue Jan 30, 2019

Fixed fzf issue on ubuntu with kubectl query ahmetb/kubectx#123

Closed

lungtendo mentioned this issue Jan 31, 2019

Error in vim: Error running 'fzf' '-m' '--prompt' '~/g/gr/' --expect=ctrl-v,ctrl-x,ctrl-t --height=26 #1487

Closed

15 tasks

junegunn mentioned this issue Jan 31, 2019

Vim plugin error Ubuntu 18.04 #1488

Closed

15 tasks

kthibodeaux added a commit to kthibodeaux/.dotfiles that referenced this issue Jan 31, 2019

Do not use fzf preview because ubuntu bug breaks it

0e9571c

junegunn/fzf#1486 (comment)

This was referenced Feb 1, 2019

"Failed to read /dev/tty" after Ubuntu update junegunn/fzf.vim#758

Closed

:Files not working since recent Vim / Ubuntu changes junegunn/fzf.vim#759

Closed

tadashi-aikawa added a commit to tadashi-aikawa/owl-playbook that referenced this issue Feb 1, 2019

fzfが使えないことの一次対応(junegunn/fzf#1486)

3c35272

tadashi-aikawa added a commit to tadashi-aikawa/owl-playbook that referenced this issue Feb 1, 2019

fzfが使えないことの一次対応(junegunn/fzf#1486)

dde7520

justinthomas mentioned this issue Feb 26, 2019

:FZF in VIM switches from NORMAL mode to REPLACE mode #1499

Closed

15 tasks

junegunn closed this as completed Mar 18, 2019

ipv7 mentioned this issue Nov 3, 2019

Failed to read /dev/tty denisidoro/navi#146

Closed

dawidd6 mentioned this issue Dec 15, 2019

Failed to read /dev/tty when trying to execute "glo" wfxr/forgit#64

Closed

10 tasks

ofrades mentioned this issue Jul 19, 2020

Vim popups in Tmux #2116

Closed

10 tasks

michal-h21 mentioned this issue Aug 17, 2020

ZettelOpen and ZettelSearch fail because of an "Error running fzf..." michal-h21/vim-zettel#58

Open

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

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

Comments

erch commented Jan 29, 2019 • edited Loading

winvicta commented Jan 29, 2019

bartels commented Jan 29, 2019

ianchanning commented Jan 30, 2019 • edited Loading

ianchanning commented Jan 30, 2019 • edited Loading

ianchanning commented Jan 30, 2019 • edited Loading

tanc commented Jan 30, 2019

tanc commented Jan 30, 2019

ianchanning commented Jan 30, 2019

tanc commented Jan 30, 2019

ianchanning commented Jan 30, 2019

tanc commented Jan 30, 2019

bartels commented Jan 30, 2019

lungtendo commented Jan 31, 2019

taranjlu commented Jan 31, 2019 • edited Loading

lungtendo commented Feb 1, 2019 • edited Loading

vhakulinen commented Feb 2, 2019 • edited Loading

ianchanning commented Feb 2, 2019

vhakulinen commented Feb 2, 2019

bartels commented Feb 2, 2019

stephentalley commented Feb 2, 2019

kthibodeaux commented Feb 2, 2019

vhakulinen commented Feb 3, 2019

nickgronow commented Feb 13, 2019

junegunn commented Feb 14, 2019

JiHyeongSeo commented Feb 14, 2019

Karmenzind commented Feb 15, 2019

diegolealco commented Feb 15, 2019

ianchanning commented Feb 16, 2019 • edited Loading

ianchanning commented Feb 18, 2019 • edited Loading

nickgronow commented Feb 18, 2019

mrvon commented Feb 19, 2019 • edited Loading

marcinpraczko commented Feb 21, 2019

ianchanning commented Feb 21, 2019 • edited Loading

moonwater commented Mar 1, 2019

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.

rtucek commented Mar 5, 2019 • edited Loading

pgebheim commented Mar 6, 2019

daveyarwood commented Mar 7, 2019 • edited Loading

dnmfarrell commented Mar 13, 2019

butla commented Mar 14, 2019

daveyarwood commented Mar 14, 2019

piroux commented Mar 17, 2019 • edited Loading

njohnson7 commented Nov 14, 2019

PhilippOrtnerUp2Go commented Nov 20, 2019

75re commented Mar 24, 2020

ofrades commented Jul 19, 2020 • edited Loading

junegunn commented Jul 21, 2020

erch commented Jan 29, 2019 •

edited

Loading

ianchanning commented Jan 30, 2019 •

edited

Loading

ianchanning commented Jan 30, 2019 •

edited

Loading

ianchanning commented Jan 30, 2019 •

edited

Loading

taranjlu commented Jan 31, 2019 •

edited

Loading

lungtendo commented Feb 1, 2019 •

edited

Loading

vhakulinen commented Feb 2, 2019 •

edited

Loading

ianchanning commented Feb 16, 2019 •

edited

Loading

ianchanning commented Feb 18, 2019 •

edited

Loading

mrvon commented Feb 19, 2019 •

edited

Loading

ianchanning commented Feb 21, 2019 •

edited

Loading

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.

rtucek commented Mar 5, 2019 •

edited

Loading

daveyarwood commented Mar 7, 2019 •

edited

Loading

piroux commented Mar 17, 2019 •

edited

Loading

ofrades commented Jul 19, 2020 •

edited

Loading