mintty-bash-ssh weirdness after remote disconnect during vi session

[Thomas Wolff]

Am 05.07.2025 um 18:17 schrieb Jim Garrison via Cygwin:
> On 7/4/2025 18:49, Thomas Wolff via Cygwin wrote:
>>
>> Am 05.07.2025 um 03:04 schrieb Jim Garrison via Cygwin:
>>> I've recently started seeing weirdness in mintty/bash after a 
>>> connection to a remote system is terminated by the remote.  So far 
>>> this seems to happen only if the remote session was interrupted 
>>> while vi was running.
>>>
>>> After the session is interrupted, here's what happens on the local 
>>> (Windows/cygwin) mintty window:
>>>
>>> * Ctrl-D just rings the tty "bell"
>>>
>>> * Any change of window focus, in Windows, for the mintty window itself,
>>>   causes the tty bell to ring
>>>
>>> I researched this by opening a second terminal session and using 
>>> that to kill various processes in the remote tree: ssh-bash-vi and 
>>> found that just killing the vi process causes the issue.  On the 
>>> remote system, Ctrl-D produces the string "0;5u".  Exiting the 
>>> remote session (via 'exit') then leaves the local mintty in the same 
>>> state.
>>>
>>> I guess it's because vi remaps keystrokes and they didn't get reset 
>>> when vi died, but my usual goto 'stty sane' does not fix the 
>>> problem, neither on the remote nor local systems.
>> Certainly a good guess. You can check your state with `stty -a`, for 
>> example about ^D behaviour.
>>
>>> Is there a way to reset mintty other than closing and reopening it?
>> Try the `reset` command. Or the `Reset` function from the context 
>> menu, also via Alt+F8.
>
> `reset` does the trick.  However my curiosity is piqued since it 
> appears the remote vi somehow remapped a lot of keystrokes in the 
> local mintty. In fact, it seems to have mapped ALL the uppercase 
> letters to escape sequences... but left all the lowercase letters, 
> numbers and puctuation alone.
That is xterm modifyOtherKeys mode, which editors like to use because it 
allows to distinguish modifier combinations in more detail than the 
traditional keyboard layout supports.

> Interesting, but probably not worth spending any time on. It's just 
> part of the "undefined but not really unexpected" behavior when you 
> pull the rug out from under a program that remaps terminal keystrokes 
> for its own use :-)
In fact, as you had already described yourself. It's more about certain 
modes than key remapping. Also, `reset` resets the terminal while `stty 
sane` resets the tty/pty, so it is a good idea to combine both, just in 
case.