Arrow keys not working in Bash for Windows

[Ordspilleren]

The new Bash for Windows has just been released in the latest Windows 10 Insider Preview. I have added bash.exe in a new task in ConEmu, and it launches just fine. However, the arrow keys do not work in the bash environment (they work fine when launching bash.exe normally). I have tried revealing RealConsole by pressing Ctrl+Win+Alt+Space, and the arrow keys work just fine in that environment. My ConEmu configuration is the default one.

I am not sure what other information I can provide, feel free to request any additional info, I will do my best to provide such.

[Maximus5]

Is it your question? http://stackoverflow.com/q/36467150/1405560

I'm not sure. Perhaps the switch -new_console:p1 may help. Add it afer bash.exe -l -i.

[Ordspilleren]

Yes, that is the issue. When bash is launched through ConEmu, the arrow keys never work, not for command history or in Vim / Nano. Adding -new_console:p1 did not work.

[reflog]

I also get this message when opening the console:
mesg: /dev/tty: Operation not permitted

I wonder if it's related?

[Maximus5]

I have absolutely no idea yet, how "bash in Windows" was implemented. But last message looks like a luck of implementation.

[nuclearmistake]

The arrow keys work running Windows 10 bash in a cmd window... and it would appear as though whatever is in between bash.exe and the actual executable is pretty substantial... within the bash shell, there's full-on apt-get (pointed at trusty repos), the windows %PATH% isn't on $PATH, and trying to run notepad.exe from inside bash.exe (...inside cmd.exe) reports that the binary has an unsupported format.

Seems that windows 10 bash is leveraging some of the "new terminal features" that cmd.exe has options for, as it refuses to run if cmd.exe is set to legacy mode... the gist of those features is outlined (for windows server 2016) @ https://technet.microsoft.com/en-us/library/mt427362.aspx

[lennylxx]

As far as I know, the C:\Windows\System32\bash.exe is just a wrapper and installer which is used to extract tarball called lxss.tar.gz to C:\Users\<name>\AppData\Local\lxss\rootfs.

It's not an actually Bash at all.
So I don't think adding options like bash.exe -l -i will work, since Microsoft may not have plan to make it compatible with the MSYS2 bash.exe.

Microsoft bash.exe only can be fed one option for now like C:\Windows\System32\bash.exe ~ to start with path navigated to you home directory.

I tried the RealConsole of ConEmu, arrow keys does work in the real console window.
I also read #183 and moby/moby#13817, the problem is similar but it seems having different reason.

[Ordspilleren]

@lennylxx It is not just a wrapper, it IS bash. Try typing bash.exe --help. Many of the traditional bash options found in there will work. As for installing / uninstalling, bash doesn't do that at all. A separate utility called lxrun does all of that with i.a. lxrun /install and lxrun /uninstall. As such, since bash.exe is quite literally bash ported to a windows executable, options like -l -i will work fine in theory. However, as @reflog found out, the -l command will return mesg: /dev/tty: Operation not permitted, probably because Microsoft hasn't implemented handling for that yet.

To resolve this issue, I have personally tried to change most of the keyboard configuration options inside Ubuntu itself to see if it is simply because Ubuntu itself doesn't know how to handle the inputs, but nothing seems to work. I'd assume the issue is that bash.exe expects a format of inputs that only the improved Windows Console Host in this Insider Preview can provide. Adding to that, it's not only the arrow keys that don't work, the del, end, home etc. keys don't work either.

[lennylxx]

@Ordspilleren Yes, you're correct about the installer, I've double checked that. I'm surprised you found the lxrun.exe, didn't notice it before.

But bash.exe IS a wrapper of /bin/bash and feeds all the options to the real bash, because I checked the disassembly of it and I found that it will first launch an installer and then execute /bin/bash in rootfs. You can see a string /bin/bash at address 0xAFA0 using a hex editor.

The 'kernel' which is LxssManager is already running, so we don't need to fully re-implement a bash using WinAPI, just run it on the 'kernel'.

[watzon]

I'm also having this issue

[pandada8]

btw, all readline features also not working

[Maximus5]

That all looks like a bash.exe bug. But I can't insist until I check it.

[alexleonard]

I'm having this issue as well. Any left/right/up/down cursor key usage doesn't work, but does work in bash when running it via cmd.exe. Cursor keys in ConEmu before launching bash.

[Hooter]

And do not work Function keys (F1-F12)

[ivanarnold]

Thanks for your awesome work. Would just like to comment that I also am experiencing this and would love to see it fixed.

Thanks again for conemu. It's awesome.

[selalipop]

It's a little frustrating reading the thread from the last time people had this issue, which was months ago. I have no idea why there's an insistence to place the blame on the programs having this issue. Bash On Windows has working arrow keys when I run it through:

• cmd
• powershell
• cmd called from powershell
• powershell called from cmd
• arbitrarily nested instances of powershell and cmd

Since this program is supposed to emulate the behavior of a Windows console, why is this behavior not clearly a problem with this program as opposed to the programs that are working correctly in the default console?

Edit: Also works as expected on Console2

[Maximus5]

@ErrantErinaceinae Are you kidding? Months??? The issue was created four days ago! This is absolutely new feature of Windows 10! It's beta at last and may have bugs!

[selalipop]

thread from the last time people had this issue

referred to #183, which has comments that outline this exact issue but with another shell (the git-bash shell). The referenced issue in that thread fixed Docker but there was no further talk of the issue with git-bash.

I don't think it's unreasonable to assume they're related. And again, I fail to see how expected behavior applying in all the contexts I mentioned but failing in this one program is a bug with the feature unless I'm misunderstanding something about the meaning of "Windows console emulator".

And there's no need for the excessive punctuation and bolded excerpts, I can follow what you say just fine without them.

[Maximus5]

Issue #183 was related to the bug of Docker. The problem of this (#629) issue has not been located yet, but of course it's different, because Bash-for-Windows is absolutely new product.

[selalipop]

As I said in that comment, the referenced issue in that thread fixed Docker but there was no further talk of the issue with git-bash, not Docker. The issue with git-bash that a series of comments in that thread mentioned mirrors the exact behavior I'm seeing now.

[Maximus5]

The only workaround: Build 160411 (or higher) and start bash as following:

%windir%\system32\bash.exe -cur_console:p1

[interpeix]

I'm sorry, I tryed that and it still doesn't work for me :(

[KayLeung]

@Maximus5 Thanks! It works!
@interpeix,
default Bash task in Build 160411 doesn't set -cur_console:p1 by default.

[interpeix]

Sorry, my bad. I see what you say @KayLeung, thanks @Maximus5 works fine.

[Ordspilleren]

@Maximus5 Thank you very much for the workaround, it seems to work beautifully!

The only issue that remains is the lack of support for international characters like æøå. This does not work in the official Bash on Ubuntu on Windows either, so I imagine it's up to Microsoft to fix that.

[Maximus5]

Disability to type characters with codebase >127 is definitely bash problem. Even chcp 65001 doesn't help. The problem should be reported on BashOnWindows.

[Maximus5]

BTW, what do you think, what name should be given to the task? {Bash::Bash on Ubuntu} is rather long...

[Ordspilleren]

@Maximus5 I have personally just named mine {Bash::bash} since that is the most descriptive, short name I could come up with. The actual name is Bash on Ubuntu on Windows, but that is of cause hopelessly long.

[Maximus5]

Keys are working in WSL that's why this issue is closed.

[chx]

They do in shell but they don't in iex and MySQL has some issues too which in Linux typically surface over SSH when term is mismatched.

[Maximus5]

@chx Did you try to compare iex behavior with other terminals? Which? What ConEmu version do you use? How do you start the WSL?

[chx]

I have a shortcut to "C:\Program Files\ConEmu\ConEmu64.exe" wsl but I also tried conemu-cyg-64.exe --wsl -cur_console:pm:/mnt to the same results. Arrows work when I start bash then iex from a plain cmd window. Apparently I am on 180114 preview.

[chx]

Here is a simplified bug report: if I start a plain cmd and I run bash then cat then I get ^[[D when pressing the left arrow. Under conemu I get ^[OD. No iex needed.

[Maximus5]

Old Builds

[Maximus5]

https://conemu.github.io/en/BashOnWindows.html#arrows-sol-2

[chx]

YES! Switching off Appkeys helped. Nothing else. How do I get it to stay switched off across terminals, reboots and such?

[rahar]

How can I do that AppKeys will be enabled by default? Turning on AppKeys helped me.

[Maximus5]

Run default task for your shell

[elijahgagne]

In case this helps, in one of the newer versions of ConEmu, I wasn't getting the default AppKeys settings for a new custom task. I changed my custom task to include -new_console:p5 and that fixed it for me. See
https://conemu.github.io/en/NewConsole.html for p[N] - pty modes meaning.

[rahar]

Thanks, that helped! I had to add "-l" param to the exec so that my login (zsh) shell will run

[Maximus5]

In current builds in you use default tasks (with connector) AppKeys must be activated when console request them. Otherwise it may be a bug (of ConEmu or shell).

[yellow-sock]

The out of the box behaviour for ConEmu 180626 [64] and latest WSL with latest ubuntu didn't work for me.
After trying all kind of different command line options adding -new_console:p5 did it for me.
Thanks elijahgagne!

[Maximus5]

@yellow-sock The default ConEmu behavior is exposed by command

ConEmu64.exe -basic -run {bash}

I doubt you have tried it

[yellow-sock]

@Maximus5 I didnt try it. I was assuming that it does the same as when I select Bash::bash from the menue. When I try it i get:

The above picture was made with my current bash config (which is the one that works for me):

Something wrong with my installation ?

[Maximus5]

when I select Bash::bash from the menue. When I try it i get:

On your screenshot you run absolutely different task than you show on the second screenshot.

https://conemu.github.io/en/DefaultTasks.html

[lucaswunder]

Hey everyone, digit the number of the line and hit enter, works for me

[PeterFogh]

I just added the vim command :set term=builtin_ansi and then the arrows works. Therefore, I have added the command to my .vimrc file. cd $HOME && printf '"# Fix the use of keyboard arrows in vim. \n:set term=builtin_ansi' >> .vimrc

[sunaku]

See if tput rmkx helps: it turns off "application mode" which causes the arrow keys to behave differently.

[iam3fun]

Hey everyone, digit the number of the line and hit enter, works for me

Thank you Lucas!

[calra123]

I faced the same problem while using eslint on git bash, I found this workaround useful - https://stackoverflow.com/a/58521883/11261701

[picorealm]

I'm experiencing the non-working arrow keys issue with ConEmu 191912 (Preview) while running Cygwin BASH (using the default {Bash::CygWin bash} task on Windows 10 version 1909.

[ravermeister]

I'm experiencing the non-working arrow keys issue with ConEmu 191912 (Preview) while running Cygwin BASH (using the default {Bash::CygWin bash} task on Windows 10 version 1909.

me too

[danijeldomazetprivate]

Same here, arrow keys not working in Bash::CygWin. Adding p5 did not help.

[pccasto]

For those with recent comments on this closed issue. Problem is different - Issue with a change in cygwin. See #2035

[asuiu]

-new_console:p5 fixed the issue for me.