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. Getting xterm-kitty onto every system in the universe is also implausible. Furthermore these days many applications assume xterm-like terminal behavior anyway.Įxpanding or extending ssh across the world would be an immense task (there are many implementations), and ssh isn't the only tool that carries $TERM values from system to system. ![]() The whole idea of passing a $TERM value 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 infamous rxvt-unicode-256color), battling to get some new entry added everywhere, and declaring success at the 95% mark. 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. ("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/ (I usually find xterm-256color a good compromise.)Īs Kovid warns, this does seem to break some things, e.g. Since I am very definitively in the 1% not well served by an ssh-wrapper, I would love to set $TERM to something more widely understood than xterm-kitty. ![]() I'm happy to write a FAQ appendix as needed. I'm intimately familiar with terminfo/termcap and Unix terminal handling in general, and can receive arcane specifics without needing explanation. I'm very curious for a deeper explanation here, including the specific definitions that need to get nailed down. 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. Why insist on using xterm-kitty instead of something more widely recognized like xterm-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. More philosophically, the ssh-wrapper approach feels like a brittle solution with significant possibility of unanticipated and surprising outcomes. I don't know how common these use cases are, but there are plenty of threads about various aspects of this problem. It's not at all uncommon to log in as captive users without write permissions. It's not at all uncommon to log into non-Unix systems with ssh (embedded systems, console drivers, other operating systems, etc). These assumptions are decidedly not true all of the time. That it's possible and acceptable to modify the user's home directory.That it has a termcap/terminfo type system.That /bin/sh and various other tools work in more or less standard ways. ![]() However, the ssh kitten makes a lot of assumptions about the destination machine: Consequences and issuesįor 99% of users, this works 99% of the time. ![]() To make this convenient, there is an ssh kitten which wraps the ssh command with something that replaces the user's command with a shell script that tries to install the xterm-kitty terminal definition file before launching whatever the user originally wanted (a specific command or just a login shell). Since kitty is not yet especially mainstream, this often means adding xterm-kitty to the remote machine's termcap/terminfo database, at least on a per user basis. Since $TERM is carried through many remote-login protocols ( ssh, but also the old telnet, rlogin, etc) this means that every system one plans to log into must be "kitty-ified". Per the FAQ (and numerous answers to individual questions), it is strongly, strongly recommended to use term xterm-kitty (which sets $TERM to xterm-kitty) when using kitty. 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. I just want to talk! And maybe capture the situation and its ins and outs, for the record.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |