Repository navigation
Default all G-sets to ASCII unless ISO-2022 is requested (was: Terminal breaks on \x1b O) #10408
Description
Windows Terminal version (or Windows build number)
1.8.1521.0
Other Software
OpenSSH_5.3p1
Steps to reproduce
- SSH to linux server (for me it's CentOS, if it matters)
echo -e '\x1bo'
Expected Behavior
I expect that terminal will continue to work properly
Actual Behavior
I can no longer type "actual" text in terminal, every key press transforms in a mess seen on screenshot. CTRL+Something sequences are also no longer working.
Stumbled upon this issue when I was debugging gsm7 encodings in python program (\x1b is a common byte for this encoding). On yet another 'print()' terminal became a mess.
Issue is not reproduced if i'm using powershell.exe or cmd.exe without it being embeded in WT.
Activity
KalleOlaviNiemitalo commentedon Jun 11, 2021
ESC 06/15 is LS3 - LOCKING-SHIFT THREE. That was implemented in #4496.
Have you tried the same command in a different terminal, such as xterm or in the Linux console? I expect you'd get the same result with those.
iamdbychkov commentedon Jun 11, 2021
I have no problem running mentioned command on the same server while using putty as my gui ssh client / winsshterm (which is putty)/penguinet and no problems with Debian's default console.
KalleOlaviNiemitalo commentedon Jun 11, 2021
From https://www.man7.org/linux/man-pages/man4/console_codes.4.html, I get the impression that the Linux console does not implement LS3, while xterm does.
KalleOlaviNiemitalo commentedon Jun 11, 2021
Is there already a feature request for an action that resets the character sets to the defaults? Similar to #1882 for the scrollback.
[-]Winodws terminal breaks on \x1b O if connected to remote server using ssh. [/-][+]Windows terminal breaks on \x1b O if connected to a remote server using ssh. [/+]j4james commentedon Jun 11, 2021
FYI, typing
resetin bash should fix this. I also sometimes include a soft reset (\x1b[!p) in my prompt, which fix most issues like this automatically. But an action would be good too - I think most terminal emulators have something like that. I'm sure we've discussed this before actually, but I can't find an existing issue for it now, so maybe I'm misremembering.iamdbychkov commentedon Jun 13, 2021
Yes, thank you, typing reset in bash indeed worked, but unfortunately it won't work in the environments like python console, one in which I initially discovered the issue
j4james commentedon Jun 13, 2021
If it happens again in a python console, you can use
print '\x1bc'to reset. Not suggesting that's a good long term solution, but it's better than having to exit and restart.WSLUser commentedon Jun 14, 2021
Can you bump your Win32-OpenSSH to 8.6? https://github.com/PowerShell/Win32-OpenSSH/releases
Before 8.1, it was handling VT sequences itself instead of allowing conhost to do so instead.
iamdbychkov commentedon Jun 15, 2021
Sadly, it didn't make a difference:
WSLUser commentedon Jun 15, 2021
j4james commentedon Jun 15, 2021
I'm fairly certain OpenSSH has nothing to do with this. As KalleOlaviNiemitalo pointed out at the start, LS3 is a standard control sequence that is intended to change the character set - it's working as designed. You'll get the exact same behaviour in a local shell. What we're missing, is a way for users to easily reset the terminal when it gets into a state that they weren't expecting.
zadjii-msft commentedon Jun 15, 2021
It seems totally reasonable to me for us to have a "Reset Terminal" command ~~that's just a
sendInput("\x1bc")command,~~bound by default. Good thinking.It can't just be a sendInput command - it'll need to immediately trigger it like it was sent as client output, but yea it's a good idea.
21 remaining items
j4james commentedon Jul 6, 2021
Yeah, that make sense to me. Although we may want to skip the bit about the setting the G-sets correctly when switching to ISO-2022 mode if we want to remain forward-compatible with
DECAUPSSbeing added later. I'm not totally sure about that, but either way is OK with me. As long as there is some series of escape sequences a user can send to get things the way they want, then I think we're good.If you mean in a setting, then ideally yes. It was certainly a user-controlled setting in the original hardware terminals, and I suspect most real terminal emulators would have a setting for it. If combined with a way to start up in ISO-2022 mode, it would enable users to easily run legacy 8-bit applications designed for a particular code page.
That said, I don't think there's a huge demand for that sort of thing anymore, so it's not essential if you don't want WT to go that route. Also, it would have to wait until we have a proper conpty pass-through implementation, since all the character set mapping is currently handled on the conhost side.
Default all G-sets to ASCII unless ISO-2022 is requested (#11658)
Default all G-sets to ASCII unless ISO-2022 is requested (#11658)
Default all G-sets to ASCII unless ISO-2022 is requested (#11658)