I just installed this on my server via ssh and got this error when I pressed CTRL+R:
$(__fzf_history__)panic: Failed to open /dev/tty
goroutine 8 [running]:
github.com/junegunn/fzf/src/curses.Init(0xc82000e180, 0x470100)
/go/src/github.com/junegunn/fzf/src/curses/curses.go:261 +0xc9
github.com/junegunn/fzf/src.NewTerminal.func1()
/go/src/github.com/junegunn/fzf/src/terminal.go:233 +0x36
github.com/junegunn/fzf/src.(*Terminal).Loop(0xc820058b60)
/go/src/github.com/junegunn/fzf/src/terminal.go:744 +0x368
created by github.com/junegunn/fzf/src.Run
/go/src/github.com/junegunn/fzf/src/core.go:202 +0xe84
goroutine 1 [semacquire]:
sync.runtime_Syncsemacquire(0xc820018350)
/go1.5/src/runtime/sema.go:237 +0x201
sync.(*Cond).Wait(0xc820018340)
/go1.5/src/sync/cond.go:62 +0x9b
github.com/junegunn/fzf/src/util.(*EventBox).Wait(0xc82000e520, 0xc82004bef0)
/go/src/github.com/junegunn/fzf/src/util/eventbox.go:32 +0xb5
github.com/junegunn/fzf/src.Run(0xc82000c2c0)
/go/src/github.com/junegunn/fzf/src/core.go:275 +0xfb2
main.main()
/go/src/github.com/junegunn/fzf/src/fzf/main.go:6 +0x25
goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/go1.5/src/runtime/asm_amd64.s:1696 +0x1
goroutine 5 [syscall]:
os/signal.loop()
/go1.5/src/os/signal/signal_unix.go:22 +0x18
created by os/signal.init.1
/go1.5/src/os/signal/signal_unix.go:28 +0x37
goroutine 11 [runnable]:
github.com/junegunn/fzf/src.(*Terminal).Loop.func2(0xc82001c540, 0xc820058b60)
/go/src/github.com/junegunn/fzf/src/terminal.go:736
created by github.com/junegunn/fzf/src.(*Terminal).Loop
/go/src/github.com/junegunn/fzf/src/terminal.go:741 +0x330
goroutine 7 [semacquire]:
sync.runtime_Syncsemacquire(0xc820018390)
/go1.5/src/runtime/sema.go:237 +0x201
sync.(*Cond).Wait(0xc820018380)
/go1.5/src/sync/cond.go:62 +0x9b
github.com/junegunn/fzf/src/util.(*EventBox).Wait(0xc82000e580, 0xc820028f60)
/go/src/github.com/junegunn/fzf/src/util/eventbox.go:32 +0xb5
github.com/junegunn/fzf/src.(*Matcher).Loop(0xc8200127e0)
/go/src/github.com/junegunn/fzf/src/matcher.go:67 +0x93
created by github.com/junegunn/fzf/src.Run
/go/src/github.com/junegunn/fzf/src/core.go:197 +0xe18
goroutine 9 [runnable, locked to thread]:
runtime.gopark(0x622d40, 0xc82001c478, 0x5dd050, 0x9, 0x16, 0x3)
/go1.5/src/runtime/proc.go:185 +0x163
runtime.goparkunlock(0xc82001c478, 0x5dd050, 0x9, 0x16, 0x3)
/go1.5/src/runtime/proc.go:191 +0x54
runtime.chansend(0x55ee20, 0xc82001c420, 0xc82002970c, 0xc820029601, 0x453369, 0x2)
/go1.5/src/runtime/chan.go:197 +0x499
runtime.chansend1(0x55ee20, 0xc82001c420, 0xc82002970c)
/go1.5/src/runtime/chan.go:92 +0x43
runtime.ensureSigM.func1()
/go1.5/src/runtime/signal1_unix.go:238 +0x2a9
runtime.goexit()
/go1.5/src/runtime/asm_amd64.s:1696 +0x1
goroutine 10 [chan receive]:
github.com/junegunn/fzf/src.(*Terminal).Loop.func1(0xc82001c3c0, 0xc820058b60)
/go/src/github.com/junegunn/fzf/src/terminal.go:730 +0x36
created by github.com/junegunn/fzf/src.(*Terminal).Loop
/go/src/github.com/junegunn/fzf/src/terminal.go:732 +0x1e2
Can you tell me more about your server?
It's a Classic VPS from OVH. I'm running Ubuntu 15.10, with a uname of
Linux starbeamrainbowlabs.com 2.6.32-042stab111.12 #1 SMP Thu Sep 17
11:38:20 MSK 2015 x86_64 x86_64 x86_64 GNU/Linux
I connect to it via SSH - I do have access to it's console, but that
uses the web interface and it's kinda ugly - I much prefer SSH. I can't
change my kernel, interestingly enough - OVH update it automagically for
me. Other than that, I have full root access and can do what ever I want.
I have a single virtual core running at 2GHz I think, 1GB or RAM, and
10GB of hard drive space.
On 11/12/15 07:38, Junegunn Choi wrote:
Can you tell me more about your server?
—
Reply to this email directly or view it on GitHub
https://github.com/junegunn/fzf/issues/447#issuecomment-163866119.
ssh command to connect? Then try using -t option which forces pseudo-terminal allocation.Here's an extract from htop: http://i.imgur.com/5eaR1xB.png
Edit: Image disappeared for some reason.
Interesting.
ruby -rio/console -e'p IO::console'?cat /proc/tty/driversHere's an extract from my terminal:
sbrl@starbeamrainbowlabs:~$ ruby -rio/console -e'p IO::console'
nil
sbrl@starbeamrainbowlabs:~$ cat /proc/tty/drivers
cat: /proc/tty/drivers: No such file or directory
sbrl@starbeamrainbowlabs:~$ ls /proc/tty
ls: cannot access /proc/tty: No such file or directory
sbrl@starbeamrainbowlabs:~$ ls /proc
1 15882 22384 26331 359 5781 fairsched stat
10 15998 22385 26332 363 5803 fairsched2 swaps
11 16899 22387 26687 370 5817 filesystems sys
12 19670 22392 27588 4 6 fs sysrq-trigger
12289 2 22393 27590 405 6671 kmsg sysvipc
12439 20258 22394 27808 423 7 loadavg uptime
13995 20333 22395 27918 427 77 locks user_beancounters
14391 22200 22399 28192 442 8 meminfo version
14399 22376 22402 28240 443 9 modules vmstat
14552 22379 23661 28241 461 cgroups mounts vz
14684 22380 23662 28260 463 cmdline net
14685 22381 23663 2948 5 cpuinfo partitions
15880 22383 24712 3 556 devices self
What is the output of tty command?
(We can find the file name of the terminal with the command. However, we _can't_ use the output instead of hard-coded /dev/tty since fzf is usually used as a filter where stdin is not the terminal)
Right, I _think_ I understand. Here's the output of the tty command:
sbrl@starbeamrainbowlabs:~$ tty
/dev/pts/0
Wish I could help, but I can't simulate such environment neither on linux nor on osx where /dev/tty is unavailable but tty command succeeds.
When I connect to a remote host via ssh with -T option which disables pseudo-terminal allocation, /dev/tty becomes unavailable and fzf fails with the same error you reported, but tty command as well fails and vim or top do not work smoothly as expected.
> echo $TERM
dumb
> cat /dev/tty
cat: /dev/tty: No such device or address
> tty
not a tty
> fzf
panic: Failed to open /dev/tty
...
> top
TERM environment variable not set.
> TERM=xterm top
top: failed tty get
...
Is there anything I can do to help?
Hmm, can you try connecting to the server with -tt option, e.g. ssh -tt ..., or maybe even -ttt though I'm not sure if it makes any difference, but some people suggested using -ttt, so.
Excerpt from the man page:
-t Force pseudo-terminal allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be
very useful, e.g. when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty.
@junegunn Nope, no luck with -ttt. I still get /dev/pty/0. Here's the output from the above commands again whilst logged in with -ttt:
sbrl@starbeamrainbowlabs:/tmp/fzf$ ruby -rio/console -e'p IO::console'
nil
sbrl@starbeamrainbowlabs:/tmp/fzf$ cat /proc/tty/drivers
cat: /proc/tty/drivers: No such file or directory
sbrl@starbeamrainbowlabs:/tmp/fzf$ cat /proc/tty/
cat: /proc/tty/: No such file or directory
sbrl@starbeamrainbowlabs:/tmp/fzf$ ls /proc
1 13995 15882 23661 27492 27502 27564 31948 405 5 9 filesystems mounts sysrq-trigger
10 14391 15998 23662 27494 27503 27565 31949 423 556 cgroups fs net sysvipc
11 14399 16899 23663 27495 27505 27777 31950 427 6 cmdline kmsg partitions uptime
12 14552 19670 24712 27496 27508 27778 359 442 6671 cpuinfo loadavg self user_beancounters
12289 14684 2 27264 27499 27510 27810 363 443 7 devices locks stat version
12439 14685 20258 27489 27500 27511 2948 370 461 77 fairsched meminfo swaps vmstat
13537 15880 20333 27490 27501 27512 3 4 463 8 fairsched2 modules sys vz
sbrl@starbeamrainbowlabs:/tmp/fzf$ tty
/dev/pts/0
I could perhaps create you a limited temporary account on my server if you are unable to replicate a suitable testing environment.
A bit more information about my server: It's virtualized using OpenVZ, and I'm using the latest RHEL kernel to my knowledge.
I've just tried PuTTY, but I still get pty/0.
Another update:
I've taken a look at the code, and think the problem lies in src/curses.go on line 259 (I haven't learnt go though). The code makes the assumption that /dev/tty is available, when in reality it isn't always. Perhaps a better approach would be this:
tty command. If it succeeds, then try opening the path that it returns./dev/tty.That would catch every possible scenario.
I still get /dev/pty/0
The output itself is not invalid. The absence of /dev/tty and other terminal programs still working nevertheless is the situation I've never experienced and fzf is not the only program that assumes the existence of /dev/tty. e.g. https://gitlab.com/procps-ng/procps/blob/master/ps/global.c#L136
I briefly mentioned about the approach you suggested in the previous comment. STDIN to fzf is usually not terminal (e.g. history | fzf) so tty command will fail and will not give the file name we can use (history | tty fails).
I could perhaps create you a limited temporary account on my server if you are unable to replicate a suitable testing environment.
Probably this is the only way I can take a look at the problem, though I'm not sure if I'll be able to find the solution. It would be much better if you could create a Dockerfile that can be used to create a virtual machine with the same environment locally.
Docker file? How do I do that? I haven't encountered docker before.
I haven't been able to find a way not to rely on /dev/tty for getting key presses when stdin is redirected. /dev/tty is a standard linux device name and the absence of it usually means non-interactive terminal. Any help is appreciated.
@junegunn If I open /dev/tty on my laptop with cat, anything I type into it get's echoed back as expected. If I do the same on the server, I get a permission denied.
If, however, I run the tty command, on the server it returns /dev/pty/0, and on my laptop it returns /dev/pty/4. Opening them both with cat on their respective machines works like a charm.
Would it be possible to try opening /dev/tty, and if that fails run the tty command to determine the terminal to try next?
No, like I said above, tty command is not the answer. We normally use fzf with stdin redirection, e.g. history | fzf. And what do we get when we do history | tty? not a tty error.
By the way, I have never seen /dev/tty missing on interactive shell on Linux servers. RHEL, Centos, Ubuntu, Nixos, Arch linux, NixOS, never had the problem. Have you tried contacting OVH about it?
@junegunn Ah I see. That _is_ a problem. I have just tried contacting OVH and pointed them towards this bug - hopefully I'll get a response in a day or two.
Here's the message I sent:
Hello,
I have recently been taking a look at some software that I wanted to install on my VPS, but the software in question is unable to open /dev/tty, and the developer has advised me to contact you.Here's a link to the issue with the software in question: https://github.com/junegunn/fzf/issues/447
Did you get any response?
@junegunn Thanks for reminding me to update this issue! I think I did, yeah, but it boiled down to the virtualisation tool they used for the 2014 range of VPSes. I'm renting a different (much better!) server now, so it should work. I'll check it out :D
For the users running into this after Ubuntu update, it's a kernel regression. See https://github.com/junegunn/fzf/issues/1486
Most helpful comment
For the users running into this after Ubuntu update, it's a kernel regression. See https://github.com/junegunn/fzf/issues/1486