PSReadLine
PSReadLine copied to clipboard
PowerShell
Linux/Mac/VT: PSReadline in PowerShell 7 rc3 goes ballistic if you do not respond to its request for cursor position
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.
PSReadLine depends on querying for the cursor position to work properly. What would be the expected behavior in those terminal emulator then?
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?
I would expect it to not dump memory to the screen and then crash without a message, in any case!
Very reasonable 😄
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.
~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 👍)
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?
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.
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.
93m is bright yellow, the @ is just incidentally next to it and not part of the sequence :)
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.
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 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?
So I fixed my issue by reading from stdin for user input instead of using the Console APIs.