Replies: 12 comments 7 replies
-
|
On Mon, Jul 26, 2021 at 09:14:17PM -0700, Daniel Egnor wrote:
However, the ssh kitten makes a lot of assumptions about the destination machine:
- That it's vaguely Unix-like
Does *interactive* SSH actually work on non Unix like systems?
- That `/bin/sh` and various other tools work in more or less standard ways
The ssh kitten relies on POSIX tools only, as far as I know. If you are
trying to log into non POSIX systems, you are on your own.
- That it has a termcap/terminfo type system
What system other than termcap/terminfo uses the TERM variable?
- That it's possible and acceptable to modify the user's home directory
If you are not going to modify the home directory at all, what is it you
are doing on the remote server in an interactive session? Modifying
files belonging to someone else? Simply the act of logging into an
interactive session will modify files in your home directory (the shell
will write history/login info), sshd will write to its log files, etc.
So I dont see what's so egregious about writing one file into
~/.terminfo
These assumptions are decidedly _not_ true all of the time. It's not at all uncommon to log into non-Unix systems with `ssh` (embedded systems, console drivers, other operating systems, etc). It's not at all uncommon to log in as captive users without write permissions. I don't know how common these use cases are, but there are plenty of threads about various aspects of this problem.
See above.
More philosophically, the ssh-wrapper approach feels like a brittle solution with significant possibility of unanticipated and surprising outcomes.
I cant think of any unanticipated or surprising outcome, other than, the
terminfo database failing to be copied as a result of which things
will not work. Which is the same thing you risk with setting TERM to
whatever. Feel free to enlighten me.
The medium term robust solution is for the ssh daemon to copy the
terminfo database onto the remote server when running an interactive
session.
IMHO, it _seems_ better just to relegate terminfo/termcap to the past, emulate xterm faithfully, set `$TERM` to some widely understood value, and use other mechanisms (such as live detection) for apps to detect when specific extensions are available. BUT, I say this not knowing the probably very good reasons why Kovid has gone to great lengths to try to keep everyone on `xterm-kitty`.
The very good reason is that live detection is *slow* and *complex*. It
involves a round trip to the terminal emulator. It is *eminently* not
suited for quick invocation command line tools. Therefore, one needs
some form of terminal capabilities database. Sadly the one we are stuck
with is terminfo. Efforts to replace it have failed:
https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/8
So we are stuck with terminfo. And terminfo's maintainer is, to be
polite, less than ideal. See #879 or
https://gist.github.com/XVilka/8346728#detection
Since kitty aims to move the terminal ecosystem forward, it cannot
have the only way to detect its capabilities without a roundtrip be tied
to the boat anchor that is xterm and ncurses.
|
Beta Was this translation helpful? Give feedback.
-
|
To be clear, I'm not trying to pick a fight, I super love what you're doing with kitty, I'm just poking a bit at this particular edge. I hadn't bumped into #879 which is interesting reading for sure.
Again, I think it all works fine for 99% of users 99% of the time, but here's some of what's in the 1%:
Again these are arguably obscure cases and tend to be used by more skilled users who can find workarounds. In fact I am one of those relatively skilled users (on a good day, anyway). But I'd rather I didn't have to find workarounds. Most importantly I need to know what will break when
And I admire that attitude for sure! Doing anything innovative in this space always requires picking some careful battles about which ancient stone pyramids to carefully preserve which which to bulldoze. (So much about this evolved ecosystem is ludicrous...) Anyway, what I'm hearing is that the main issue is detecting kitty-specific capabilities (above and beyond the generic terminal types) without the delay of a probing round-trip. In that case, it seems like setting My super humble modest proposal: Leave A lot of distros already pass and accept (I'm sure there are Many Issues with this...) |
Beta Was this translation helpful? Give feedback.
-
|
On Tue, Jul 27, 2021 at 01:34:49AM -0700, Daniel Egnor wrote:
To be clear, I'm not trying to pick a fight, I super love what you're doing with kitty, I'm just poking a bit at this particular edge. I hadn't bumped into #879 which is interesting reading for sure.
> Does *interactive* SSH actually work on non Unix like systems?
> If you are not going to modify the home directory at all, what is it you are doing on the remote server in an interactive session?
> I cant think of any unanticipated or surprising outcome, other than, the terminfo database failing to be copied as a result of which things will not work. Which is the same thing you risk with setting TERM to whatever. Feel free to enlighten me.
Again, I think it all works fine for 99% of users 99% of the time, but here's some of what's in the 1%:
- Cisco switches (IOS), IBM mainframes (z/OS), embedded RTOS (VxWorks, etc), console servers (Opengear, etc) all support interactive ssh logins and care about terminal type to some degree. Some of them ignore the ssh terminal type entirely (no problem!), others have some set of accepted types that includes things like `vt100` and `xterm` but certainly not `xterm-kitty`. And I sure as heck don't want to run a bunch of Bourne-shell-intended code on a Cisco router. (_Hopefully_ I'd just get a syntax error. Admittedly, it's been many years since I was logging into those on the regular.)
All of these run some flavor of UNIX, so I dont see the problem.
It's not bourne shell, it's POSIX. And if you dont want to run anything
on the server (a completely illogical attitude to me, given that you
will be running an entire shell, but that's your choice), write a five
line script that copies the compiled terminfo db and then sshes in. If
you want to be thorough about it, use a ssh controlmaster so there is no
performance penalty either.
- Stripped-down mini Unix-based systems often have static terminfo files and no `tic` type command. You've gotten questions about those, your answer is to copy things over manually, which can work if the home directory is writable (by no means a given, they often have no/little writable filesystem) but is obviously a hassle if it's a thing one is doing a lot.
Same as above.
- Sysadmins of large cluster/cloud operations often log in as users that have no home dir (or a read only home dir), and then gain specific privileges (`sudo` or similar) to take any actions. When you have hundreds or thousands of machines it's important not to let the state of individual machines wander (otherwise things get unpredictable) hence the lockdown.
A terminfo db in ~/.terminfo is not server state. It is never used by
anything in the absence of TERM=xterm-kitty which nothing on the server
will set, other than SSH, when it is needed.
- Firewall/VPN gateway servers often have a locked down account users "bounce" through, first you log into the gateway and then you run another ssh (or other) command to get where you're going. The account on the gateway has no writable home dir because it's a bounce pad shared by lots of users.
I assume you mean using ssh -J. This should work perfectly transparently
with the ssh kitten, though I haven't actually tested it.
Again these are arguably obscure cases and tend to be used by more skilled users who can find workarounds. In fact I am one of those relatively skilled users (on a good day, anyway). But I'd rather I didn't have to find workarounds. Most importantly I need to know what will break when `$TERM` is not `xterm-kitty`. The current messaging reads as "everything will break! don't do it!" which isn't as helpful as knowing "ok, kitty-specific utilities like `icat` and remote control won't work, but nothing will explode". Or maybe something will explode? I was surprised by that kitty shell issue!
They are indeed edge cases and ones that have perfectly serviceable
workarounds in about five minutes of scripting. terminfo is used for
everything from keypresses (the cause of readline and hence kitty shell
breakage), to how to erase the screen or a line, to how to reset the
terminal to how to switch to alternate modes, etc, etc. Just read man
terminfo. With a mismatched terminfo literally *anything* can break.
> Since kitty aims to move the terminal ecosystem forward, it cannot have the only way to detect its capabilities without a roundtrip be tied to the boat anchor that is xterm and ncurses.
And I admire that attitude for sure! Doing anything innovative in this space always requires picking some careful battles about which ancient stone pyramids to carefully preserve which which to bulldoze. (So much about this evolved ecosystem is ludicrous...)
Anyway, what I'm hearing is that the main issue is detecting kitty-specific capabilities (above and beyond the generic terminal types) without the delay of a probing round-trip. In that case, it _seems_ like setting `$TERM` to some "generic" value like `xterm` or `xterm-256color` or whatever could be documented (and debugged) as "you'll lose kitty goodies, but everything else should work". Am I wrong?
No, the main issue is I need a way to be able to add capabilities
to kitty's terminfo database without being gatekeepered by xterm.
That is important because querying the terminal is not acceptable
in too many contexts.
My super humble modest proposal:
Leave `$TERM` and terminfo to rot. Use a second environment variable to describe terminal extensions (anything above and beyond ECMA-48). Call it `$LC_TERM_ABILITIES`. Instead of the terminfo format it would just be a colon delimited list of functionality names, including well known things like `color8bit` or `color24bit` and also namespaced/experimental things like `net.kovidgoyal.kitty` (or `net.kovidgoyal.kitty.graphics` if you want to be more granular). Programs would use the ones they understand and ignore the ones they don't so adding extensions is never a problem.
A lot of distros already pass and accept `$LC_*` variables over ssh so you're almost done (this is a hack but a tight one). No need to wade through a committee, just do it and tell your friends who enjoy pretty terminal things. Get the node folks (the biggest fans of fancy terminal eyebleed I've met) on board and you're golden. And sure, offer a kitten that tunnels `$LC_TERM_ABILITIES` by wrapping `ssh`, for cases where the variable isn't already passed and people miss the extra capabilities on the remote end and they're not worried about obscure cases. Boom! Everything is great and nobody is complaining.
(I'm sure there are Many Issues with this...)
You say that getting the kitty terminfo onto all machines is impossible,
based on a bunch of edge cases. And yet you seem to think that I can
wave a magic wand and get an env var through all those edge cases. I can
guarantee that your various stripped down boxen will not pass through
LC_*. Hell, even my laptop based on Arch doesnt::
LC_NO_CHANCE=1 ssh localhost env | grep LC
|
Beta Was this translation helpful? Give feedback.
-
|
[shameless buttering 🧈 - reminder that I find Kitty is incredibly great, fast, flexible and thoughtfully designed, a reminder of the golden era of desktop creativity and hopefully a harbinger of new greatness 😻] My takeaway is: Those of us who (for whatever reason) run with (And if we spend you PRs to clarify your FAQ entries a bit, you'll consider them, but no guarantees!) Sound about right? Back into the trenches below, feel free to ignore if this has already eaten too much of your time.
(I am intimately familiar with terminfo, sadly...) You put a ton of effort, which I appreciate, into making kitty backward-compatible with xterm at the escape code level (ignoring weird nonsense like Tektronix graphics). (I'm pretty sure it's a ton of effort because I've written terminal emulators and know it's a pain to get all the edge cases right.) So, With
The difference is in graceful fallback and backward compatibility. If If It's a tradeoff between sometimes losing capability vs sometimes failing entirely (with different rates of each). I like the graceful fallback option myself but I can see different viewpoints here. The 🕊️ |
Beta Was this translation helpful? Give feedback.
-
|
On Tue, Jul 27, 2021 at 11:39:02AM -0700, Daniel Egnor wrote:
My takeaway is: Those of us who (for whatever reason) run with `$TERM` != `xterm-kitty` are doing something "unsupported". You've given us a kitty config setting, which we appreciate, and if we find stuff that's broken, we're free to send you PR's, but you're not going to spend time debugging it, because you're just not interested in that particular compatibility path; you'd rather spend the energy finding ways to get `xterm-kitty` recognized everywhere, ideally in an automatically distributed way; you feel like that's the best path for the ecosystem in general.
(And if we spend you PRs to clarify your FAQ entries a bit, you'll consider them, but no guarantees!)
Sound about right?
You are free to send PRs for pretty much anything, I will accept or
reject them based on their individual merits. If you think the topic is
likely to be controversial, open an issue first to discuss it, to avoid
wasting your time.
I am indeed not going to spend time on TERM != xterm-kitty issues.
Back into the trenches below, feel free to ignore if this has already eaten too much of your time.
> terminfo is used for everything from keypresses (the cause of readline and hence kitty shell breakage), to how to erase the screen or a line, to how to reset the terminal to how to switch to alternate modes, etc, etc. Just read man terminfo. With a mismatched terminfo literally *anything* can break.
(I am intimately familiar with terminfo, sadly...)
You put a ton of effort, which I appreciate, into making kitty backward-compatible with xterm at the escape code level (ignoring weird nonsense like Tektronix graphics). (I'm pretty sure it's a ton of effort because I've written terminal emulators and know it's a pain to get all the edge cases right.)
A pain and a half!
So, `$TERM=xterm` really should work, given any terminfo/termcap definition that works with xterm itself. This is not an arbitrarily mismatched terminfo. (Of course if you set `$TERM=vt52` kitty won't work, neither will xterm, but nobody's doing that.)
Not quite, there are some places I intentionally diverge from xterm,
most notably bce and few of the more exotic keys. You can check for
yourself easily using infocmp to diff terminfo.
With `$TERM=xterm` you wouldn't get fancy extensions that allow displaying images and whatnot, but at least basic compatibility should be there. Notably, readline-using programs work just fine under kitty with `$TERM=xterm`, the inbuilt kitty shell must be doing something different. I'll try to figure out what it is. (It sure looks like it just uses vanilla readline in a straightforward way, so it's a bit of a mystery.)
I will note that
kitty --config NONE -o term=xterm
has kitty shell working fine for me.
> You say that getting the kitty terminfo onto all machines is impossible, based on a bunch of edge cases. And yet you seem to think that I can wave a magic wand and get an env var through all those edge cases. I can guarantee that your various stripped down boxen will not pass through LC_*. Hell, even my laptop based on Arch doesnt.
The difference is in graceful fallback and backward compatibility.
If `$TERM=xterm` and `$LC_TERM_ABILITIES` (or whatever "second path") is lost or ignored, you end up with vanilla xterm compatibility, which should work just fine, even if you don't have as many fancy colors and image display options. (Those obscure systems couldn't use that anyway.) That feels like a good, graceful, backward compatible fallback. (And, passing `$LC_TERM_ABILITIES` is an easy, robust ssh config option.)
The thing you are missing is that if the path is extremely unreliable,
as LC_* would be, the larger ecosystem wont use it for detection. So we
need some mechanism that is relatively reliable. And terminfo, with the
ssh kitten, is the best I can come up with without support from either
kernel developers or openssh developers.
If `$TERM=xterm-kitty` and the destination doesn't understand `xterm-kitty`, then you get error messages and don't have terminal support at all. (And if you use the `ssh` kitten and the destination doesn't speak POSIX shell syntax, then you get error messages and no login at all.) That seems like an unfortunate incompatibility.
Note the destination can use whatever shell it likes, what the ssh
kitten requires is that */bin/sh* be POSIX compatible. That's a pretty
basic requirement, which if your system does not follow, lots of other
things will break.
|
Beta Was this translation helpful? Give feedback.
-
|
I found this discussion because I've been bumping in to the same problem when logging in to remote systems that have a rather pared-down terminfo database. My workaround has been to set Since we can't expect |
Beta Was this translation helpful? Give feedback.
-
|
Do you find that |
Beta Was this translation helpful? Give feedback.
-
|
@ewhac thank you so much. Your suggestion here saved the day for me |
Beta Was this translation helpful? Give feedback.
-
|
I know this is an OLD thread, but I've just run into this using teleport. When I use tsh ssh server_name to log in, I get the issue of the terminal being set to xterm-kitty and things get funky in my fish session on the remote server. Pretty sure the wrapper isn't going to help me here because I have no way to run it over the teleport connection as far as I know. Is there a way to update the remote system without using the wrapper that would help here? |
Beta Was this translation helpful? Give feedback.
-
|
On Mon, Sep 25, 2023 at 05:37:39PM -0700, Peter Nunn wrote:
Is there a way to update the remote system without using the wrapper that would help here?
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you. I missed the link to the manual copy. I'll give it a go. |
Beta Was this translation helpful? Give feedback.
-
|
While reading
Could kitty add an option to pass the contents of |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, I tested passing in TERMINFO into a container environment that doesn't have kitty's terminfo installed, and it works like a charm! See https://chromium-review.googlesource.com/c/chromiumos/bazel/+/5383676. |
Beta Was this translation helpful? Give feedback.
-
|
On Wed, Mar 20, 2024 at 12:41:18PM -0700, Raul E Rangel wrote:
Could kitty add an option to pass the contents of `xterm-kitty` in the `TERMINFO` variable?
I can certainly add that, but note that this is likely supported only by
ncurses itself. Other libraries/software will probably fail with
TERMINFO not set to a path.
|
Beta Was this translation helpful? Give feedback.
-
|
And here you go: 198b69e |
Beta Was this translation helpful? Give feedback.
-
|
For ssh usage, I find useful to use the |
Beta Was this translation helpful? Give feedback.
-
|
oh thank god! This is what I've been needing. @kovidgoyal seems particularly defensive about this damn kitten, but I am constantly running into issues with the kitty terminal setup over SSH. We tend to use scripts to SSH into cloud instances where we are pulling keys from vault, loading into ssh-agent, and then logging into the machine, and even if I create a wrapper script for ssh which calls "kitten ssh" under the hood it just hangs. I think this should be the default for remote kitty terminals, and the xterm-kitty should only be used when explicitly using the ridiculous kitten command. |
Beta Was this translation helpful? Give feedback.
-
|
Wouldn't it be better to use But yeah, really annoying that it's not compatible out of the box. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
I just want to talk! And maybe capture the situation and its ins and outs, for the record. Many many apologies if this was hashed out somewhere (I couldn't find it on quick search), I'll happily delete this if it's redundant or unwelcome.
The situation as I understand it
Per the FAQ (and numerous answers to individual questions), it is strongly, strongly recommended to use
term xterm-kitty(which sets$TERMtoxterm-kitty) when using kitty.Since
$TERMis carried through many remote-login protocols (ssh, but also the oldtelnet,rlogin, etc) this means that every system one plans to log into must be "kitty-ified". Since kitty is not yet especially mainstream, this often means addingxterm-kittyto the remote machine's termcap/terminfo database, at least on a per user basis.To make this convenient, there is an
sshkitten which wraps thesshcommand with something that replaces the user's command with a shell script that tries to install thexterm-kittyterminal definition file before launching whatever the user originally wanted (a specific command or just a login shell).Consequences and issues
For 99% of users, this works 99% of the time.
However, the ssh kitten makes a lot of assumptions about the destination machine:
/bin/shand various other tools work in more or less standard waysThese assumptions are decidedly not true all of the time. It's not at all uncommon to log into non-Unix systems with
ssh(embedded systems, console drivers, other operating systems, etc). It's not at all uncommon to log in as captive users without write permissions. I don't know how common these use cases are, but there are plenty of threads about various aspects of this problem.More philosophically, the ssh-wrapper approach feels like a brittle solution with significant possibility of unanticipated and surprising outcomes.
Why?
Why insist on using
xterm-kittyinstead of something more widely recognized likexterm-256color? The reasons aren't documented that I can find, but I assume the intent is to control the terminfo definition so that it precisely matches what kitty implements. Furthermore it may allow kitty-aware tools (such as the remote controller and anything which uses kitty-specific extensions) to detect kitty's presence or absence and behave accordingly.I'm very curious for a deeper explanation here, including the specific definitions that need to get nailed down. I'm intimately familiar with terminfo/termcap and Unix terminal handling in general, and can receive arcane specifics without needing explanation. I'm happy to write a FAQ appendix as needed...
Alternatives?
Since I am very definitively in the 1% not well served by an ssh-wrapper, I would love to set
$TERMto something more widely understood thanxterm-kitty. (I usually findxterm-256colora good compromise.)As Kovid warns, this does seem to break some things, e.g. #3870. ("If you change TERM everything will break" was the reply; "everything" is surely hyperbole, but at least some things do break!) It seems possible to remedy the problems I've seen, but I definitely don't understand all the issues/
To be clear, terminfo/termcap is such an old and weird system that I don't think there's an architecturally right way to solve any related issue. The whole idea of passing a
$TERMvalue around without passing a definition is asking for trouble, and effectively leads to everyone settling on some commonly understood core, and occasionally people extending it (as in the infamousrxvt-unicode-256color), battling to get some new entry added everywhere, and declaring success at the 95% mark. Furthermore these days many applications assume xterm-like terminal behavior anyway.Expanding or extending
sshacross the world would be an immense task (there are many implementations), andsshisn't the only tool that carries$TERMvalues from system to system. Gettingxterm-kittyonto every system in the universe is also implausible.IMHO, it seems better just to relegate terminfo/termcap to the past, emulate xterm faithfully, set
$TERMto some widely understood value, and use other mechanisms (such as live detection) for apps to detect when specific extensions are available. BUT, I say this not knowing the probably very good reasons why Kovid has gone to great lengths to try to keep everyone onxterm-kitty.Beta Was this translation helpful? Give feedback.
All reactions