`Console.ReadKey()` doesn't work for keys from the numeric keypad in the PuTTY ssh client

[daxian-dbw]

Original issue: PowerShell/PowerShell#10511

We got report that when ssh from PuTTY to a Linux machine and start pwsh on the server side, pwsh doesn't support the numeric keypad.
It turns out to be an issue with Console.ReadKey and the PuTTY client, see PowerShell/PowerShell#10511 (comment). Quoted below:

This is an issue in .NET Core, as Console.ReadKey() generates unexpected ConsoleKeyInfo for key pressing from numeric keypad when ssh'ed through PuTTY.
For example, you will the following when pressing 0 on the numeric keypad:

PS:1> [System.Console]::ReadKey()
O
KeyChar Key  Modifiers
------- ---  ---------
     O   O Alt, Shift

That PowerShell doesn't handle the keypad is one thing, but that it messes it up for everyone else is Real Bad(tm).

It's messed up by the .NET Core runtime. As soon as you start any dotnet application, you will be left in this "Real Bad" situation.
For example, just run pwsh -help, which only prints out the help content and exit. Then you will find all keypad keys are non-functional in bash.

[adamsitnik]

@eiriktsarpalis can it be related to #802 ?

[eiriktsarpalis]

It seems very likely, though we'd probably need to test putty just to be sure. @daxian-dbw Am I right to assume this doesn't occur using a different terminal and ssh?

[adamsitnik]

@daxian-dbw ping

[daxian-dbw]

Sorry for missing the comments here.

Am I right to assume this doesn't occur using a different terminal and ssh?

I presume so. There were similar reports in PowerShell repo, but all had Putty as the ssh client.
I use the Windows OpenSSH client in box and WSL for ssh connections, and the numeric keypad works fine with them.

[Zastai]

Some test results:

I upgraded powershell to the current latest version (7.0.2) on the linux box.

Then I logged on using PuTTY and typed 789/* using the numeric keypad at 3 points:

1. right after connecting
2. after starting pwsh
3. after exiting pwsh

This results in:

1. 789/*
2. OwOxOy (in yellow); the / and * produce no output (and no terminal bell)
   Note: In pwsh 6.2, this was slightly different; I think that had [Ow[Ox[Oy
3. nothing (and the terminal bell sounds for each keypress)
   This remains my biggest concern - keys should not stop working because a .NET app was run.

Using WSL2 Debian in Windows Terminal, all three cases produce 789/*.

Next I checked Emacs (because it has specific names for various keys), in console mode using PuTTY.
There, 789 are each seen as that letter and / and * are seen as f2 and f3, respectively.
Note that in X mode, Emacs sees these keys as kp-7, kp-8, kp-9, kp-divide, and kp-multiply.

Using WSL2 Debian, it sees 789/* all as themselves, not keypad versions, but also not unrelated function keys.

My guess is: most Linux apps use termcap/terminfo/readline, which include remappings for some escape sequences. So their input methods translate things like ^[Ow to 7.
But that only explains why pwsh doesn't see 789/*, not why the keys break after it ends.

[broudy3]

3. nothing (and the terminal bell sounds for each keypress)
   This remains my biggest concern - keys should not stop working because a .NET app was run

I do not know much about terminals, but it looks like .NET app is using DECKPAM command to enter "Keypad application mode", but it is NOT using DECKPNM to enter "Keypad Numeric mode" again.

This is the relevant strace:

write(1, "\33[?1h\33=", 7)              = 7
  /usr/lib/x86_64-linux-gnu/libpthread-2.31.so(write+0x4f) [0x12fef]
  /home/user/test/libSystem.Native.so(SystemNative_SetKeypadXmit+0x47) [0xfb67]
  unexpected_backtracing_error [0x7ff6793d1385]

This command can be used to enter "Keypad Numeric mode" again:

echo -e "\033>"