Repository navigation
Linux pwsh enables DECCKM, but Windows pwsh cannot handle it; arrow keys stop working after exiting linux powershell #12268
Description
Steps to reproduce
- Use Windows PowerShell 7 and PowerShell 7 in WSL.
- Launch Windows Powershell in Windows Terminal
- Launch wsl,
pwsh - Exit Linux powershell
- Observe the arrow keys
Linux powershell emits the escape sequence DECSET DECCKM[1] on startup before it emits the first prompt.
This reconfigures the cursor keys, which usually emit CSI A...D, to emit SS3 A...D instead.
Linux powershell can handle SS3 arrow key sequences. This is fine.
When Linux powershell exits, it does not restore DECCKM to its original state. All applications that manipulate global terminal state are expected to return the terminal to "normal" once they are done.
Because the state is not restored when you exit Linux powershell, Windows powershell (which doesn't know that the terminal state has been changed) will start to receive SS3 arrow key sequences.
Windows powershell cannot handle SS3 arrow key sequences, and it ignores them, so the arrow keys do not work.
This also reproduces when you SSH to a linux machine, but WSL is easier for a self-contained repro.
Expected behavior
DECCKM is disabled on exit.
Actual behavior
DECCKM remains enabled on exit, downstream applications get confused.
Environment data
(dhowett-sl) ~ % $PSVersionTable
Name Value
---- -----
PSVersion 7.0.0
PSEdition Core
GitCommitId 7.0.0
OS Microsoft Windows 10.0.19041
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
(dhowett-sl) ~ % wsl pwsh -c '\$PSVersionTable'
Name Value
---- -----
PSVersion 7.0.0
PSEdition Core
GitCommitId 7.0.0
OS Linux 4.19.84-microsoft-standard #1 SMP Wed Nov 13 11:44:37 UTC 2019
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
[1] Notes about DECCKM
CSI ? Pm h
DEC Private Mode Set (DECSET).
Ps = 1 ⇒ Application Cursor Keys (DECCKM), VT100.
DECCKM reconfigures the arrow keys as follows
Key Normal Application
-------------+----------+-------------
Cursor Up | CSI A | SS3 A
Cursor Down | CSI B | SS3 B
Cursor Right | CSI C | SS3 C
Cursor Left | CSI D | SS3 D
-------------+----------+-------------
[2] I've investigated PowerShell, PSReadline and dotnet/runtime, and I cannot determine where DECCKM is being enabled.
Activity
DHowett-MSFT commentedon Apr 6, 2020
Originally filed: microsoft/terminal#5257
LookoutHill commentedon Apr 6, 2020
Dustin L. Howett (MSFT) (@DHowett-MSFT) As a workaround it seems like one could create a script that would emit the appropriate reset sequence. Would you post this sequence in PowerShell string format?
DHowett-MSFT commentedon Apr 6, 2020
LookoutHill commentedon Apr 6, 2020
Thanks for that. It gave me enough info to interpret this arcane knowledge. That sequence doesn't restore functionality, but the "Reset to Initial State" sequence ("`ec") does.
DHowett-MSFT commentedon Apr 6, 2020
It legitimately looks like it's being stripped out of the output.
When I type this:
I get this out of the pty:
but when I run this:
I get
I wonder why it's being filtered from powershell's output stream. Similar sequences, like "`e[?2004l", are not.
DHowett-MSFT commentedon Apr 6, 2020
As a workaround, you can do this:
Masking that you're requesting DECRST 1 by placing a
;before it confuses powershell, but Terminal can understand it.iSazonov commentedon Apr 7, 2020
Wow!
/cc Dongbo Wang (@daxian-dbw) who have huge experience in the area.
DHowett-MSFT commentedon Apr 8, 2020
Of note, this reproduces without PSReadline available 😄
(I tracked down why I can't forcibly print "`e[?1l" -- PowerShell isn't using VT input on Windows, so that value is technically meaningless to it. Conhost is ignoring it.)
lukaszroz commentedon Sep 1, 2020
I have come across this bug when I SSH from Ubuntu to Windows machine. It works when I SSH from Bash without starting PowerShell. To reproduce in PowerShell on Ubuntu in Gnome Terminal:
After some digging I have found dotnet/corefx#6488. The Pull Request fixed a number of bugs related to terminal escape codes handling. It seems to me the DECCKM might be set in System.Console, see lines 937 - 947
lukaszroz commentedon Sep 1, 2020
Found the issue: dotnet/runtime#27626
DHowett commentedon Sep 1, 2020
Excellent investigation. Thanks!
tig commentedon Oct 21, 2020
Tagging TylerLeonhardt so he's aware of this relative to https://github.com/PowerShell/GraphicalTools
Specifically, this is why
out-consolegridviewhas issues on Linux where the cursor keys don't work after using it. Related to PowerShell/ConsoleGuiTools#99.16 remaining items
wez commentedon Mar 4, 2021
Please also disable that mode when running child processes!
iSazonov commentedon Mar 4, 2021
Wez Furlong (@wez) Welcome to review #14943. You can download artifacts there and check its locally.
wez commentedon Mar 4, 2021
I don't particularly want to dive into the code in powershell; I'm here because cli/cli#3071 was initially reported as a bug in my terminal emulator :-p
The test scenario is:
gh auth loginiSazonov commentedon Mar 4, 2021
Wez Furlong (@wez) You can just download the compiled artifacts, tests them in your environment and give a feedback before the PR will be merged.
mklement0 commentedon Mar 4, 2021
Wez Furlong (@wez), you can emulate what the PR will implement as follows:
For entire-session support - as a stopgap that should also work for older PS versions - you can place the following at the end of your
$PROFILEfile (assumes use ofPSReadLine, which is true by default):wez commentedon Mar 4, 2021
Thanks, but I don't use powershell; as I mentioned above, I'm just here because this issue was raised by one of the users of my terminal. Bernát Gábor (@gaborbernat): perhaps you could try those suggestions?
gaborbernat commentedon Mar 4, 2021
I can confirm that Michael Klement (@mklement0) solution works on:
fix: parse SS3 cursor key sequences in read_key