[System.Console]::ReadKey() returns escape sequence characters when pressing arrow keys in PowerShell on Linux

[daxian-dbw]

Description

This is with PowerShell 7.3.0-preview.7, which runs on top of .NET 7-preview.7.

Running [System.Console]::ReadKey() in PowerShell, and then press UpArrow, it returns the escape sequences character by character -- Escape and then A.
It's the same to other arrow keys: DownArrow, LeftArrow, RightArrow

However, when using Console.ReadKey in an EXE built against .NET 7-preview.7, it returns UpArrow (and other arraow keys) as expected. Any ideas about what may cause this difference?

Related PowerShell issue: PowerShell/PowerShell#16443

Reproduction Steps

1. Run PowerShell 7.3.0-preview.3, which runs on top of .NET 7-preview.7.
2. Run [System.Console]::ReadKey()
3. Press UpArrow

Expected behavior

[System.Console]::ReadKey() returns a ConsoleKeyInfo with those values: KeyChar: 0, Key: UpArrow, Modifier: 0

Actual behavior

[System.Console]::ReadKey() returns a ConsoleKeyInfo with the Escape key, and then a second ReadKey returns A

However, when using Console.ReadKey from an EXE that's built against .NET 7-preview.7, it works as expected:

Regression?

Not as far as I know. I observe the same behavior in .NET 6.

Known Workarounds

No response

Configuration

Which version of .NET is the code running on?
.NET 7-preview.7

What OS and version, and what distro if applicable?
Ubuntu 18.04

What is the architecture (x64, x86, ARM, ARM64)?
x64

Other information

No response

[ghost]

Tagging subscribers to this area: @dotnet/area-system-console
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

This is with PowerShell 7.3.0-preview.3, which runs on top of .NET 7-preview.7.

Running [System.Console]::ReadKey() in PowerShell, and then press UpArrow, it returns the escape sequences character by character -- Escape and then A.
It's the same to other arrow keys: DownArrow, LeftArrow, RightArrow

However, when using Console.ReadKey in an EXE built against .NET 7-preview.7, it returns UpArrow (and other arraow keys) as expected. Any ideas about what may cause this difference?

Reproduction Steps

1. Run PowerShell 7.3.0-preview.3, which runs on top of .NET 7-preview.7.
2. Run [System.Console]::ReadKey()
3. Press UpArrow

Expected behavior

[System.Console]::ReadKey() returns a ConsoleKeyInfo with those values: KeyChar: 0, Key: UpArrow, Modifier: 0

Actual behavior

[System.Console]::ReadKey() returns a ConsoleKeyInfo with the Escape key, and then a second ReadKey returns A

However, when using Console.ReadKey from an EXE that's built against .NET 7-preview.7, it works as expected:

Regression?

Not as far as I know. I observe the same behavior in .NET 6.

Known Workarounds

No response

Configuration

Which version of .NET is the code running on?
.NET 7-preview.7

What OS and version, and what distro if applicable?
Ubuntu 18.04

What is the architecture (x64, x86, ARM, ARM64)?
x64

Other information

No response

Author:	daxian-dbw
Assignees:	-
Labels:	area-System.Console
Milestone:	-

[daxian-dbw]

Is this also addressed by f1de614?

[adamsitnik]

Any ideas about what may cause this difference?

Is there any chance PowerShell could set TERM env variable?

Is this also addressed by f1de614?

I am not 100% sure as I don't know what caused the difference in first place. Could you please test it with RC1?

[daxian-dbw]

PowerShell doesn't set TERM env variable, it just derives that env variable:

PS:6> $env:TERM
xterm-256color

The PSReadLine module running in PowerShell depends on Console.ReadKey and it works as expected, however, running [Console]::ReadKey directly in PowerShell console doesn't. This is really puzzling and any help is much appreciated.

[adamsitnik]

@daxian-dbw RC1 was shipped yesterday, could you please check if it works as expected now?

[daxian-dbw]

Thanks @adamsitnik, we are preparing a release targeting RC1. Will verify this soon.

[daxian-dbw]

This is fixed with the .NET 7-RC1 release ❤️ Thanks @adamsitnik!
But I'm still curious about why it only doesn't work when running in PowerShell directly for the previous .NET versions ... what a mystery 😵‍💫

[adamsitnik]

But I'm still curious about why it only doesn't work when running in PowerShell directly for the previous .NET versions ... what a mystery

Based on #75289 (comment) it looks that I'll have to solve this mystery anyway ;)

[adamsitnik]

@daxian-dbw thanks for testing it and letting me know!