terminal: Default all G-sets to ASCII unless ISO-2022 is requested (was: Terminal breaks on \x1b O)
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.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 24 (5 by maintainers)
Commits related to this issue
- Default all G-sets to ASCII unless ISO-2022 is requested (#11658) ## Summary of the Pull Request There is a non-zero subset of applications that randomly output _Locking Shift_ escape sequences wh... — committed to microsoft/terminal by j4james 3 years ago
- Default all G-sets to ASCII unless ISO-2022 is requested (#11658) ## Summary of the Pull Request There is a non-zero subset of applications that randomly output _Locking Shift_ escape sequences whic... — committed to microsoft/terminal by j4james 3 years ago
- Default all G-sets to ASCII unless ISO-2022 is requested (#11658) ## Summary of the Pull Request There is a non-zero subset of applications that randomly output _Locking Shift_ escape sequences whic... — committed to microsoft/terminal by j4james 3 years ago
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.