Linux/Mac/VT: PSReadline in PowerShell 7 rc3 goes ballistic if you do not respond to its request for cursor position

DHowett-MSFT commented 4 years ago

Environment

PS version: 7.0.0-rc.3
PSReadline version: 2.0.0
os: Linux antares 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux
PS file version: 7.0.0.0
HostName: ConsoleHost
BufferWidth: 120
BufferHeight: 50

Also happens in Azure Cloud; this is likely in the Unix compat layer.

Steps to reproduce

Use a terminal emulator that does not respond to CSI 6 n (DSR Device Status Report 6, Cursor Position). Launch powershell. Wait.

Expected behavior

It doesn't explode.

Actual behavior

It dumps random memory to the output stream, then just exits.

daxian-dbw commented 4 years ago

PSReadLine depends on querying for the cursor position to work properly. What would be the expected behavior in those terminal emulator then?

DHowett-MSFT commented 4 years ago

I would expect it to not dump memory to the screen and then crash without a message, in any case!

Zsh doesn’t seem to need cursor position info to do highlighting. Do we really?

daxian-dbw commented 4 years ago

I would expect it to not dump memory to the screen and then crash without a message, in any case!

Very reasonable 😄

SteveL-MSFT commented 4 years ago

This seems like a .NET issue. The reason is that if you start pwsh -noninteractive which doesn't load PSRL, you get the same behavior. We should try to get a simplified repro for .NET team.

DHowett-MSFT commented 4 years ago

~That doesn’t necessarily mean that it’s not PSReadline, right? Since it was unloaded, it’s not necessarily ruled out.~

(I read the original message as though removing PSReadline helped 👍)

DHowett-MSFT commented 4 years ago

Sorry, disregard. I misread your message 😄

SteveL-MSFT commented 4 years ago

The .NET code in question is here.

daxian-dbw commented 4 years ago

It happens with pwsh -noninteractive because the built-in PowerShell console host code also query cursor position a lot. So it seems this issue will happen as long as an application try getting the cursor position within such a terminal emulator.

Also happens in Azure Cloud; this is likely in the Unix compat layer.

@DHowett-MSFT I missed this comment. Can you please share a repro using Azure Cloud Shell?

DHowett-MSFT commented 4 years ago

So, Windows Terminal 0.9 (no later) doesn’t support cursor report. If you run pwsh from bash in the included Azure Cloud Shell profile, it’ll crash like this.

SteveL-MSFT commented 4 years ago

Some traces after starting pwsh from CloudShell and just sitting at the prompt (no user input):

[Received: 1B-5B-33-38-3B-32-3B-31-35-30-3B-31-35-30-3B-31-35-30-6D-41-7A-75-72-65-3A-2F-1B-5B-30-30-6D-0D-0A-50-53-20-41-7A-75-72-65-3A-5C-3E-20-1B-5B-36-6E]
[Received: [38;2;150;150;150mAzure:/[00m
PS Azure:\> [6n]
[Send: 1B-32-3B-31-33-52]
[Send: 2;13R]
[Received: 1B-5B-36-6E]
[Received: [6n]
[Send: 1B-32-3B-31-33-52]
[Send: 2;13R]
[Received: 1B-5B-3F-32-35-6C]
[Received: [?25l]
[Received: 1B-5B-31-3B-31-48]
[Received: [1;1H]
[Received: 1B-5B-39-33-6D-40-1B-5B-33-37-6D-40]
[Received: [93m@[37m@]

The ESC isn't rendered, but is 1B. You can see a request for cursor position ESC[6n and my terminal responds accordingly ESC2;13R. Then another request for cursor and another response. ESC[?25l I believe sets VT52 and set normal video. Then cursor is set to 1,1. Then some crazy stuff happens, ESC[93m@ is received which I don't find as a valid ESC sequence.

@DHowett-MSFT note that my repro is from iTerm 2 on a mac using my cmdlet version of connecting to CloudShell.

DHowett-MSFT commented 4 years ago

93m is bright yellow, the @ is just incidentally next to it and not part of the sequence :)

SteveL-MSFT commented 4 years ago

But there's no @ in the expected output. In this case, it's literally just sitting at the prompt and my terminal and CloudShell is just talking to each other.

msftrncs commented 4 years ago

@ might mean 0x0...

SteveL-MSFT commented 4 years ago

If you look at the traces on the actual bytes received, it's 0x40 which is the at sign. Not sure where that is coming from.

SteveL-MSFT commented 4 years ago

Seems that PSRL uses @ to mean unknown input.

daxian-dbw commented 4 years ago

@SteveL-MSFT the iTerm2 supports cursor report, and IIRC the azshell works fine in your iTerm2 terminal, so what you see might not be related to this particular issue, but might be a .NET Core issue. Given that the azshell works as a standalone executable, can you maybe try separating Enter-AzShell out from PowerShell and make it a standalone .NET Core application and see if that works?

SteveL-MSFT commented 4 years ago

@daxian-dbw yeah, I'll try that out tomorrow

SteveL-MSFT commented 4 years ago

So I fixed my issue by reading from stdin for user input instead of using the Console APIs.

PowerShell / PSReadLine