Runtime: Virtual Terminal Parsing Issues

[zadjii-msft]

As we discussed over email, some parsing of virtual terminal sequences is done incorrectly. These are sequences that are generated on linux to represent certain keypresses, such as the arrow keys or the F1-F12 keys. They are also used for querying certain state about the terminal, such as the position of the cursor.

In general, the parsing works well enough on Ubuntu, however, it is noticeably wrong on the Windows Subsystem for LInux. Try running powershell on WSL, and you'll see a number of graphical defects, primarily related to the retrieving of the cursor position (see this code). Also attempting to use the arrow keys to scroll through the command history simply echos 'A', 'B', 'C', or 'D' to the input, depending on the arrow key.

As we discussed, this is probably due to .NET Core missing certain characters while parsing the result, as opposed to blocking on the input and waiting, character by character, for the complete sequence to come in.

[karelz]

@zadjii-msft which class is the bug in? Who discussed it with you?
For future: Please post relevant parts of offline discussion here for everyone to see.

[stephentoub]

He discussed it with me. The concern is that our console code reads sequences like the Cursor Position Response in a way that breaks if the terminal doesn't write positions atomically. The CPR format is ESC[row;colR. When we go to read the row, we currently read until we get a digit, and then we parse whatever digits we have in the buffer. This works fine on all of the systems we tested on, because the terminal outputs the whole row value at the same time, so when we read in the digits, we get them all. But WSL is outputting the digits individually, so it's possible or even likely that when we do our read, we only get a subset of the digits, often just the first, resulting in incorrectly reading the cursor position. I sent @zadjii-msft a fix to try yesterday.

[ianhays]

@zadjii-msft @stephentoub any update on whether the previously mentioned fix was adequate? What is remaining to do for this issue?

[stephentoub]

any update on whether the previously mentioned fix was adequate?

@zadjii-msft previously confirmed to me offline that the fix addressed the cursor position issue.

What is remaining to do for this issue?

There's still a reported issue regarding other places where we match input against terminfo data, e.g. arrow keys, such that if we only read in a partial sequence, it fails to match against what we expect, and we end up treating it like input rather than as a special sequence. Addressing that will require more thought and refactoring.

[ianhays]

Gotcha, thanks for the update.

[zadjii-msft]

Status update:

I checked in a change to WSL last week that should hopefully mitigate much of this problem. While previously, we were injecting keypresses to the subsystem one character at a time, that would not work for a number of applications for keys that generate sequences of characters. So instead the kernel injects all the characters at once, which should generally mitigate the bad cursor positioning in Powershell. I haven't run all the dotnet tests I had written before, but I believe the issue should mostly be mitigated.

This fix is moving up the source tree, should be in Insider's builds soon^tm, and in the Creator's Update release.

[karelz]

Thanks @zadjii-msft. Is there anything left for CoreFX to change? (e.g. arrow keys, as mentioned above)

[MaximoTrinidad]

Just an observation!

As in the beginning I was trying to use PowerShell 6.0 in WSL console but then the screen issues shows up. I ended up going the direction of loading and using "Ubuntu Desktop" which made PowerShell 6.0 workable enough to play with it.

Have anyone try it? I blogged about it: http://www.maxtblog.com/2017/01/windows-10-bash-and-powershell-redux/

So, I use the WSL with Windows XServer to open Ubuntu Desktop and then I can work with PowerShell.
It work fairly well. Then, I just can keep working with Python also.

I know is not support it but I kind of like it!

[danmosemsft]

this seems done?