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