Arrows ignored by bash when it started in ConEmu

[Maximus5]

I'm the author of ConEmu - alternative terminal for Windows. My users have created the issue ConEmu/ConEmu#629. When bash is started in ConEmu console, it totally ignores all extended keys (Arrows, Fn, etc.), so users can't access command line history with Up/Down arrows.

What is the problem with bash? Up/Down arrows properly cycle cmd.exe history, when it's started in ConEmu, but bash ignores them.

ConEmu is GUI application, so it get keyboard events via WM_KEYUP/WM_KEYDOWN and forward them to the created (usually hidden) real console using WriteConsoleInput.

[Maximus5]

I've created workaround in ConEmu build 160411. However, it would be nice to know, is it a bug or intended behavior.

[Maximus5]

Unfortunately, arrow keys still do not work in vim.

[sunilmut]

bash.exe has its own logic to read from console directly (this is as per the design today and subject to change in future releases). I am not a console expert, but I wonder if ConEmu interacting with the console directly is interfering with bash.exe's ability to process keyboard events?

[Maximus5]

ConEmu use official console API WriteConsoleInput to post keypressed into the conhost input buffer. That worked perfectly until "Bash on Ubuntu" appears.

[sunilmut]

Ok. I am not sure I fully understand the problem here. My understanding of this issue is that bash is not able to process arrow keys when launched from within ConEmu? Can you help clarify.

[Maximus5]

Short answer: Yes.

Many words below.
Let's take for example UpArrow key.

When user press and release UpArrow, normal console application
recieves two console key events:

1. bKeyDown = TRUE; wVirtualKeyCode = VK_UP;
2. bKeyDown = FALSE; wVirtualKeyCode = VK_UP;
   References: PeekConsoleInput, ReadConsoleInput, INPUT_RECORD, KEY_EVENT_RECORD.

But Unix console applications expect different key sequences.
For UpArrow keypress either ESC [ A or ESC O A sequences are expected
depending on requested ‘DECCKM’ mode.
References: ANSI sequence ESC [ ? 1 h and ESC [ ? 1 l.

The bash.exe is Windows console application, therefore it's expected
that this application would work properly with standard Windows console API
keypresses (KEY_EVENT_RECORD, VK_UP). But, I'm not sure who, the translation
is done when user presses UpArrow. And bash.exe recieves ESC [ A instead.

Well, that is rude workaround, but if bash.exe is started in ConEmu with
-cur_console:p1 switch, ConEmu does this translation and arrows magically
start working.

That is really rude, because ConEmu does not recieve ANSI sequences from
linux processes. And, when user starts vim from bash prompt, ‘DECCKM’ is not changed.
Therefore, ‘Arrows are not working in vim under ConEmu’.
There are absolutely no way to determine that vim was started from bash,
or vim has requested to change ‘DECCKM’ mode.
Seems like linux processes (init, bash, vim) somehow write their console output
directly to conhost, bypassing bash.exe. That's bad, because ConEmu has absolutely
no control over linux processes (started from service), only bash.exe may be hooked
to catch it's output and ‘fix’ input.

If you would like to check, download latest ConEmu build (alpha 160411 ATM),
and run from Win+R:

ConEmu.exe -basic -cmd bash.exe -cur_console:p1

[Maximus5]

Sure, it is. Monday, 02 May 2016, 07:09PM +03:00 from Daniel Gordon < notifications@github.com> :

So Just to be clear here - you guys are talking about bash.exe - that is or is not the same thing as the new Ubuntu Subsystem in the most recent Windows 10 dev build?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

[DanielGGordon]

@Maximus5 I deleted my comment because I figured it out on my own by looking at the top of this page 10 seconds after I posted my comment... Sorry for the confusion.

[dariobig]

Hi, console2 and consoleZ, two other terminal emulators, have the same problem with arrows not working on bash.

[Maximus5]

@bigonazzi Of course they are. Only ConEmu is able to send xterm-ish keyboard sequences, which LX kernel expects.

[xilun]

Just would like to add that IMO this is quite important to have WSL working properly with ConEmu, because some serious console users (myself included) are not going to be satisfied with the basic Windows Console (which is now quite better than the legacy one, but still far away from any random XWindow Console we are used to)

For now I'm doing some dev under WSL on the Windows Console (for now coping with the international keyboard bugs it has by switching to a US layout) but I will be seriously disappointed if I can't use ConEmu for a vast majority of WSL software, and that obviously includes vim...

@Maximus5 thanks for your excellent ConEmu btw :)

[dariobig]

@xilun +1

@Maximus5 I like conemu, all I'm saying is that the issue is bigger than just one program and it should be addressed with high priority.

[Darktex]

@xilun +1

The Windows default terminals don't have nearly enough features for any power user