'Failed to open controlling terminal' error when trying to remote control from vim
devth opened this issue · comments
If I try running a kitty @
remote control command from within vim, I get:
Traceback (most recent call last):
File "Python/runpy.py", line 280, in run_path
File "Python/runpy.py", line 85, in _run_code
File "kitty/__main__.py", line 119, in <module>
File "kitty/__main__.py", line 115, in main
File "kitty/__main__.py", line 22, in remote_control
File "kitty/remote_control.py", line 175, in main
File "kitty/remote_control.py", line 119, in do_io
File "kitty/utils.py", line 374, in __enter__
OSError: Failed to open controlling terminal: /dev/tty (identified with ctermid()) with error: Device not configured
It looks like this FAQ addresses it, but I'm not sure how to apply that to my situation.
For example, in vim, these commands throw the above error:
:!kitty @ ls
and
:echo system("kitty @ ls")
Presumably the environment within vim does not include a functioning tty
device. Use the --to argument to kitty @ and a --listen-on to kitty to
communicate via a dedicated socket instead.
I found this github issue trying to debug an issue with vim-slime
running on neovim.
The plugin tries to run kitty @ send-text
to send the selected text to a terminal window, but crashes instead with the Traceback in this ticket.
As it turns out, Neovim doesn't give you a tty when you run commands:
:!tty
[No write since last change]
not a tty
shell returned 1
Press ENTER or type command to continue
I got around this by setting listen-on
globally in my kitty.conf
listen_on unix:/tmp/mykitty
And rely on the KITTY_LISTEN_ON
environment variable to automatically find the socket in use. This nvim mapping is what I have started to use to send the selected text from nvim to the second window of the active tab:
vmap <silent> <leader>k ::w !kitty @ --to=$KITTY_LISTEN_ON send-text --match=num:1 --stdin<CR><CR>
You need two colons, ::
in that mapping since ::w !cmd
expands to :'<,'> :w !cmd
at runtime. More details at :help :write_c
.
I got around this by setting
listen-on
globally in mykitty.conf
listen_on unix:/tmp/mykitty
Thank you for posting this! This fixed it for me 🥳