can't edit fields in top - arrow keys not working

[timriker]

the includes "top" command watches system processes. To edit visible fields, hit 'f' and then you arrow up and down to select fields to enable or disable. The arrow keys don't get processed correctly. It looks like the "ESC" is processed before the remainder. The correct codes seem to be sent, but top and others are receiving them as individual codes instead of a sequence.

ssh into remote system and run top with the same results.

run this on a remote host and hit down-arrow and then enter, then ctrl-d on a remote host:

$ sed -n l
^[[B
\033[B$

Run the same on the local console and the up arrow looks to be interpreted by the console even though the console should be in raw mode:

$ sed -n l
\033[B$

'dd' and other similar apps also do not dump key sequences locally, but do remotely.

Side note: it would be wonderful if shift-pgup and shift-pgdn would scroll terminal history. I don't see a keyboard way of paging through terminal history.

[zadjii-msft]

So, I think this is a dupe of #418. I haven't had a chance to verify if the arrow key fixes are in the insiders build yet, but my gut feeling is that they aren't yet.

Could also be related to the TTY implementation, and the subsystem's handling of ECHOCTL. I'll need to investigate more.

[timriker]

Arrow keys work for me on remote shells now. Running:
1511 14342.1001
Yet this issue still persists both locally and remotely.

[timriker]

Issue persists on:
1511 14352.1002

[thinkingmedia]

I'm having this issue. How can I see what build my WSL is from the command line?
1607 14393.576

[zadjii-msft]

Huh. This isn't working for me either on the internal builds, despite arrow keys generally working.
The following bit seems to be the trick here:

The correct codes seem to be sent, but top and others are receiving them as individual codes instead of a sequence.

The way we handle VT-style input, the sequences do get sent to the subsystem one character at a time. I'd be curious as to why this doesn't work in top, but does in most other applications. There was a similar issue we noticed in dotnet/corefx#12452 where they would only try to parse an entire sequence, and if they received only a portion of it they would discard it as invalid, instead of waiting to receive the rest of the sequence. To the best of my understanding, that behavior is not a valid parsing of VT sequences.

I filed MSFT:10467258 on myself to internally continue this investigation.

[sunilmut]

@thinkingmedia

How can I see what build my WSL is from the command line?

The WSL version is the same as the Windows version. You can dump the Windows version using a CMD prompt, using ver. I don't know of a way to do that within bash.

[benhillis]

@sunilmut - If you're running a newer build you could do cmd.exe /c ver :)

[zadjii-msft]

tl;dr: This isn't a conhost problem. You can use top inside tmux as a workaround, or just use htop (or your favorite top fork)

After investigating this further, I believe it's the same deal as the aforementioned issue with Powershell. I believe this is the case because if you open top inside of tmux on WSL, you'll see the correct behavior.

I know that we're emitting the cursor key sequences that top is expecting. It emits 0x1b[?1h to put conhost in cursor keys application mode. Then when you press the arrow keys, we emit 0x1b[OA (etc) in accordance with the xterm spec, but for some reason, top doesn't read the entire string.

In the WSL kernel, input events are sent into the subsystem one key at a time. This is generally okay, as any VT-compliant console app should be a state machine, and not just discard partial sequences, but top doesn't appear to do that.

You can see what happens is the invalid command error message, and then the effects of typing 'A', 'B', 'C', 'D', etc correlating to the arrow key pressed. This would indicate that top discarded the partial sequence and successfully consumed the last char as a command.

If anything, this is could be a bug in the WSL kernel itself, but I believe that top is the program misbehaving in this scenario. And considering there are multiple workarounds available, I doubt this is particularly high priority. I'll defer to @benhillis's judgement.

Related issues: #933, PowerShell/PowerShell#1829, #980

[timriker]

I can't seem to find a specific spec for this, but I do recall in the old days of networking, that sending an arrow key might be interpreted as the individual characters instead of as a single escape sequence. It seems to me that network code work hard to insure that a terminal sequence is in the same TCP packet so that all characters are present. hitting ESC and then [ and then 2 and then J should be treated differently than a \e[2J sequence. I don't know if I can find a unix/posix spec that says this, but reading a character at a time is broken behavior. You could add a timeout, tracking the codes. I can't seem to find a case where this is a problem at the moment. For example, this appears to work at a shell prompt:

$ echo -n -e '\e';echo -n '[';echo -n '2';echo -n 'J'

it clears the screen the same as:

$ echo -n -e '\e[2J'

As I reported, TOP treats them differently. It sees the ESC as the ESC key, which it does a different thing with than the ESC at the start of a terminal sequence. tmux is being smart and putting the characters back together into a string.

You will find other apps that have the same issue TOP does. I think there are sequences that impact emacs users, but I don't recall what they are.

top is acting correctly. There is a spec someplace that talks about this, It's just been so many years that I can't remember where.

[zadjii-msft]

@timriker If there's any way that you can find that spec, or get me any extra details on it, that would be hugely appreciated. Because what you're saying does make sense. It'll be easier to investigate with a real spec for this behavior instead of reverse engineering it, but I can try and prototype something without it.

I'm gonna go back to the kernel code and see if there's something that can't be done about this. I believe ghci hits this too, but do you know any other apps off the top of your head that are hitting this?

[zadjii-msft]

@timriker So I went ahead and made a change to the kernel last week that fixes this. Basically, any input sequences should get injected to the subsystem atomically, like other keypresses. I know for a fact that this fixes top, and actually does a pretty good job fixing quite a few other issues as well.

Thanks for mentioning the difference between echo -n -e '\e';echo -n '[';echo -n '2';echo -n 'J' and echo -n -e '\e[2J', otherwise I don't think I would have been able to get this right!

[timriker]

@zadjii-msft great to hear! I hope it helps with other apps too. :) Thanks.