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 >
On Mon, 8 Jul 2024, Damien Miller wrote:>ssh already restores all TTY flags on exit:AIUI this is about terminal state, not tty flags, but that would require ncurses or termcap and is probably unwise. bye, //mirabilos -- Infrastrukturexperte ? Qvest Digital AG Am Dickobskreuz 10, D-53121 Bonn ? https://www.qvest-digital.com/ Telephon +49 228 54881-393 ? Fax: +49 228 54881-235 HRB AG Bonn 18196 ? USt-ID (VAT): DE274355441 Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg Vorsitzender Aufsichtsrat: Peter N?then
On Mon, 8 Jul 2024 at 11:58, Damien Miller <djm at mindrot.org> wrote:> ssh already restores all TTY flags on exit:This isn't a TTY flag, it's a terminal mode enabled via an escape sequence, there's actually multiple modes involved (CSI u as in the subject), but xterm also supports "modifyOtherKeys" and Vim for example will pick depending what the terminal reports support for. The closest thing which ssh could do would be the code equivalent of "tput rs2", but OpenSSH isn't likely to link to ncurses just for that, and it seems like for most terminals "rs1" is needed to reset the terminal key handling state (but that clears the screen too, which seems undesirable). It's worth pointing out this also reproduces if you kill -9 vim locally (on a recent Vim and a terminal which supports these key handling modes), i.e. an unexpected exit from Vim can trigger it, so SSH losing a connection where Vim can't run its exit handler is just a manifestation of the problem. As mentioned in the Kitty issue, shells should really gain support for input modes. As a workaround it would be possible to put the key reset sequence in the shell prompt or Zsh is actually programmable enough to handle unexpected CSI key sequences and then turn them off. Example .zshrc snippet: function skip-csi-sequence() { local key while read -sk key && (( $((#key)) < 0x40 || $((#key)) > 0x7E )); do # empty body done if [[ $key = u ]] || [[ $key = "~" ]]; then # Ensure keys are sent normally, zle doesn't expect modifyOtherKeys / CSI u # (This means this key press is discarded, but the next one should be handled.) printf '\e[>4m\e[<u' fi } zle -N skip-csi-sequence bindkey '\e[' skip-csi-sequence Based on that it would probably be possible to write a Zsh extension that does handle CSI u properly, which would fix this for Zsh users at least... David