Can we reset CSI u mode on client disconnect? via

Damien Miller djm at mindrot.org
Mon Jul 8 11:55:31 AEST 2024


ssh already restores all TTY flags on exit:

https://github.com/openssh/openssh-portable/blob/V_9_8_P1/sshtty.c#L56-L78

It's possible there are some exit cases that are not hitting the
leave_raw_mode(), but if so then they aren't obvious.

On Sun, 7 Jul 2024, Johannes Altmanninger 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
> 


More information about the openssh-unix-dev mailing list