Closed sergiotapia closed 5 years ago
From stackoverflow:
export TERM=xterm
And it works.
This is actually not the correct solution, see https://sw.kovidgoyal.net/kitty/faq.html#keys-such-as-arrow-keys-backspace-delete-home-end-etc-do-not-work-when-using-su-or-sudo for something that should work and https://sw.kovidgoyal.net/kitty/conf.html#opt-kitty.term for why it is a bad idea to change the TERM environment variable
So I just copy these commands verbatim into my kitty terminal?
sudo … TERMINFO=$HOME/.terminfo bash -i
sudo … env TERMINFO=$HOME/.terminfo bash -i
TERMINFO=/home/ORIGINALUSER/.terminfo exec bash -i
Either instal the kitty terminfo file system-wide or follow the instructions in the FAQ. Either approach will work.
I had to use a small workaround as the Defaults
visudo section of the FAQ didn't work for me, commented on the following issue: https://github.com/kovidgoyal/kitty/issues/579
Unless correctly supported I applied locally a quick WAD as below, no side effects yet.
#!/bin/bash
#echo "ssh.wrapper"
if [ "$TERM" = "xterm-kitty" ]; then
PATH=/usr/bin/:$PATH kitty +kitten ssh "$@"
else
/usr/bin/ssh "$@"
fi
side effects of the above
Just a quick update, the better approach is to override TERM with the globally known one when using ssh, no side effects then.
#!/bin/bash
#echo "ssh.wrapper"
if [ "$TERM" = "xterm-kitty" ]; then
TERM=xterm /usr/bin/ssh "$@" #should work most of the times, you could try any of the globally known ones e.g. screen, rxvt, vt100 etc.
else
/usr/bin/ssh "$@"
fi
You should never override TERM, TERM is how applications know what escape sequences the terminal expects, and what features it supports. You change that and things will break.
True, not ideal as any workaround. I really like kitty, great work, and use it locally but I also work with a lot of remotes so I need this wad.
One can experiment with different terminal emulators as an override, the less sophisticated one the less chance for issues. For my case xterm is fine, for others the only option can be the minimalist vt100.
@kovidgoyal I agree with @qbaze!! You are telling us not to override TERM but what other solution do we have? There is a serious problem here.
@BlueskyFR I tried the command he mentioned in his FAQ and it worked for me. Replace {server_ip} with your server IP.
kitty +kitten ssh {server_ip}
https://sw.kovidgoyal.net/kitty/faq.html keyword: terminfo
It doesn't work with sudo on an ubuntu 20.04 remote:
$ russ @ blah in ~ [14:16:15]
↳ kitty +kitten ssh ubuntu@192.168.1.64
ubuntu@bigmac:~$ sudo nano /etc/fstab
Error opening terminal: xterm-kitty.
It doesn't work with sudo on an ubuntu 20.04 remote:
$ russ @ blah in ~ [14:16:15] ↳ kitty +kitten ssh ubuntu@192.168.1.64 ubuntu@bigmac:~$ sudo nano /etc/fstab Error opening terminal: xterm-kitty.
If you have permissions on the server and you're comfortable with it, sudo apt install kitty
on the remote will solve the issue.
Installing kitty-terminfo
should be enough.
Thanks for the suggestions. I have been forcing TERM=xterm
and it's working fine.
I'm sorry guys but I don't know how kitty and other terminals with the same problem have gotten so far without some kind of automatic or manual fallback, copying files or installing packages on a remote host is not an acceptable solution in a lot of cases, and overriding TERM barely works at best, there needs to be a fallback that makes kitty use xterm internally so there's no problems connecting to any remote machine.
Possibly dumb question - I would be fine if I just could find a kitty-specific startup script so I could just:
alias ssh="kitty +kitten ssh"
just for kitty. For now I stuck this in my fish config, but would rather have this in my kitty dotfiles:
if test "$TERM" = "xterm-kitty"
alias ssh="kitty +kitten ssh"
end
Why do I need to modify systems I ssh
into just to use this terminal emulator??
Why do I need to modify systems I
ssh
into just to use this terminal emulator??
Because the key bindings it uses are not pre-installed with your system. Only the most popular terminals terminfos comes by default.
If you have permissions on the server and you're comfortable with it,
sudo apt install kitty
on the remote will solve the issue.
This is not acceptable in. I interact with hundreds of servers with different distros, and different owners, and many have ephemeral environments which only lasts one boot. Kitty is the best terminal emulator I have tried, I love it, Ive used it for over a year now, but this has gone on my nerves the whole time. I have to start looking at what is the next best terminal emulator for me. But I will be limited to whatever is supported by ncurses-terminfo. This is ridiculous. Unless the people at ncurses come to their senses and accept kitty into the fold, or at the very least explain to @kovidgoyal what they expect of him to integrate the terminfo.
I'm just frustrated, and angry at everyone except @kovidgoyal 😢
If you have permissions on the server and you're comfortable with it,
sudo apt install kitty
on the remote will solve the issue.This is not acceptable in. I interact with hundreds of servers with different distros, and different owners, and many have ephemeral environments which only lasts one boot. Kitty is the best terminal emulator I have tried, I love it, Ive used it for over a year now, but this has gone on my nerves the whole time. I have to start looking at what is the next best terminal emulator for me. But I will be limited to whatever is supported by ncurses-terminfo. This is ridiculous. Unless the people at ncurses come to their senses and accept kitty into the fold, or at the very least explain to @kovidgoyal what they expect of him to integrate the terminfo.
I'm just frustrated, and angry at everyone except @kovidgoyal 😢
I really felt the same way as you because I also connect to many remote servers, that is mainly why I switched to Alacritty. It also had its own custom terminfo but it is pre-installed with the latest versions of ncurses, and xterm (which is the default value, installed on literally every system) makes it work at 99% of its functionalities so no problem so far! I recommend you to take a look at it :)
If you have permissions on the server and you're comfortable with it,
sudo apt install kitty
on the remote will solve the issue.This is not acceptable in. I interact with hundreds of servers with different distros, and different owners, and many have ephemeral environments which only lasts one boot. Kitty is the best terminal emulator I have tried, I love it, Ive used it for over a year now, but this has gone on my nerves the whole time. I have to start looking at what is the next best terminal emulator for me. But I will be limited to whatever is supported by ncurses-terminfo. This is ridiculous. Unless the people at ncurses come to their senses and accept kitty into the fold, or at the very least explain to @kovidgoyal what they expect of him to integrate the terminfo. I'm just frustrated, and angry at everyone except @kovidgoyal 😢
I really felt the same way as you because I also connect to many remote servers, that is mainly why I switched to Alacritty. It also had its own custom terminfo but it is pre-installed with the latest versions of ncurses, and xterm (which is the default value, installed on literally every system) makes it work at 99% of its functionalities so no problem so far! I recommend you to take a look at it :)
Thank you, I will look strongly into alacritty because of what you said. I tried it before, but I couldn't do something I dont remember what, and it was so easy to do in kitty, and kitty has such good documentation, and settings. I really love Kitty, its such a shame to say goodbye to it. If I move away from kitty now, I will surly consider switching back to it at the first sign of ncurses adoption.
the solution is here: https://www.reddit.com/r/commandline/comments/prenxh/error_opening_terminal_xtermkitty/
I don't understand properly the cause of this issue, but it's acceptable to me that new softwares have compatibility issues, specially when they change old standards. Terminal is an extremely old standard which all Unix OSes work with, so developing a terminal emulator that uses new techs and go farther from the standard might break things.
I started using Kitty recently and faced this issue when accessing a server that's still on Ubuntu 20.04 which doesn't have Kitty yet. I used the kitty +kitten ssh and it's been working, even under sudo.
Either cp -r /usr/share/terminfo <destination>
or installing specific/all terminfo packages works for building a new root
Installing
kitty-terminfo
should be enough.
Still working as of 2023
Aliasing ssh='kitty +kitten ssh'
does work for remote sessions (characters behave), but colors don't work in remote sessions and vim says it has no clue about xterm-kiity, so it default to ANSI. Unfortunately, I manage hundreds of remote hosts and I use a lot of vim here and there, and this compatibility issue holds me from using kitty on my work laptop :(
Installing some random packages on remote production machines just to use a terminal emulator is absolutely unacceptable. It mustn't be thought of as a solution. I realize that kitty has so much more to offer than other older terminals. Still, I believe kitty should have a compatibility mode with older xterms to eliminate this problem, but that's my opinion. I personally don't need all of kitty features in a remote session, just bare-bones colors and proper character handling.
UPD: silly me, everything is working perfectly on 0.32.2
I've noticed that packages installed via snap
(nvtop for example) don't have access to this global terminfo. Everything else seems to work fine, but if I try to run nvtop via a shell, remotely, I get the dreaded no terminfo found. All non-snap stuff works fine, emacs, etc.
edit - you can see some snapcraft folks talking about this here- https://forum.snapcraft.io/t/handling-of-alternative-terminfo-settings-kitty-term/19256
What I've been doing is simply to ssh into the device via kitten ssh user@ip.address
once, and then you can go about your normal business after that. Be sure to do it for root
as well if you plan on doing a sudo nano ...
.
Specific for ssh, you can fix by adding SetEnv TERM=xterm-256color
into your local .ssh/config
file
Any ideas how to fix this? This is a brand new Mac.