openssh unix dev - Jul 2024 - Can we reset CSI u mode on client disconnect? via

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

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

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
>