Can we reset CSI u mode on client disconnect? via

[Jan Schermer]

There are many control codes that could be handled like this, but the logic of “reverting” something is not that simple.
What if you have ssh session with a terminal that sends this, then another inside of the first one that also sends it? One solution would be for each SSH to convert everything, the other would be to somehow reliably do a refcount… then what about a screen that gets detached and reattached inside SSH? What about having an output redirected to a terminal that didn’t receive the initial sequence?
IMO it’s safer to not handle it at all and if something breaks you can usually just “reset”.

Jan


> On 7. 7. 2024, at 16:12, Johannes Altmanninger <aclopte at gmail.com> wrote:
> 
> Some terminals support CSI u style encoding of keystrokes, typically via
> the Kitty keyboard protocol[1].
> 
> Program wishing to receive this encoding need
> to send a sequence like "CSI > 5 u" to enable it.
> 
> Imagine a process tree like
> 
> 	xterm -> bash -> ssh -> foo
> 
> where foo is any program that enables CSI u mode (such as a newfangled shell
> or text editor).
> 
> If the network connection drops, CSI u mode will remain active in xterm,
> which means that keystrokes like Control+p will be sent to bash as CSI u
> escape sequences, which bash will likely not be able to decode.
> 
> Can we make ssh reset CSI u mode when the connection drops? (by sending
> "CSI = 0 u" for example) It should not be needed on a graceful disconnect
> although it doesn't harm either.  (Or better, record the state before running
> the child process and restore it on exit)
> 
> ssh's parent process is typically a shell; if that shell uses CSI u mode,
> it should already re-enable CSI u whenever an external command finishes.
> 
> Find more discussion here[2].
> 
> [1]: https://sw.kovidgoyal.net/kitty/keyboard-protocol/#progressive-enhancement
> [2]: https://github.com/kovidgoyal/kitty/issues/7603
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev