Arrow keys not working in Bash for Windows #629

Ordspilleren opened this Issue Apr 6, 2016 · 103 comments


None yet

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 commented Apr 7, 2016

Is it your question?

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


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 commented Apr 7, 2016

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

I wonder if it's related?

Maximus5 commented Apr 7, 2016

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


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) @

lennylxx commented Apr 8, 2016

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 docker/docker#13817, the problem is similar but it seems having different reason.


@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 commented Apr 8, 2016

@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 commented Apr 8, 2016

I'm also having this issue

pandada8 commented Apr 8, 2016

btw, all readline features also not working

Maximus5 commented Apr 8, 2016

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


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 commented Apr 9, 2016

And do not work Function keys (F1-F12)


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.


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


@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!

@Maximus5 Maximus5 referenced this issue in Microsoft/BashOnWindows Apr 10, 2016

Arrows ignored by bash when it started in ConEmu #111


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.


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.


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 Maximus5 added a commit that referenced this issue Apr 12, 2016
@Maximus5 gh-629: Support xterm keyboard emulation for β€˜Bash on Ubuntu on Windo…

  conhost does not do keypressed translation, if they were posted directly to console input.
  That's why switch `-cur_console:p1` must be used to turn on internal xterm emulation in ConEmu.
  So, the task {Bash-on-Ubuntu} would be:

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

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

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

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


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


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


@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.


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


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


@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.


Arrows in vim dont work after the workaround, when pressing left arrow it shows: E388: Couldn't find definition. Other arrows do nothing.

gazben commented Apr 12, 2016

@Maximus5 I named it {GNU/Windows::Bash}. Not too short, not too long I think.


There's a workaround for vim, both local and remote

make sure ctrl+v isn't bound to paste in conemu... use ctrl+shift+v or something.

in local (AND? remote) .bashrc:

if [ -d /mnt/c/WINDOWS ] || [ $LC_WINDOWS10 ]; then
  export WINDOWS10=0
if [ $WINDOWS10 ]; then
  export LC_WINDOWS10=$WINDOWS10

in local (AND? remote) .vimrc:

let windows10=$WINDOWS10
if windows10 == '0'
  set t_ku=(ctrl+v , UP arrow)
  set t_kd=(ctrl+v , DOWN arrow)
  set t_kr=(ctrl+v , RIGHT arrow)
  set t_kl=(ctrl+v , LEFT arrow)

in vim, this will appear as "set t_ku=^[[A" or something like that.

With both the bashrc and vimrc changes in place, local and remote vim both have working arrow keys, without breaking arrow keys in non-windows10 shells.


Thanks for the update! Arrow keys work like a charm now.
But ctrl+a won't bring the cursor to the beginning of a line as normally does in bash. I already checked that it is not set to any hotkey. I guess it is related to the problem of arrow key as well.
Is there any work around?


not that I've found... maybe in the vanilla windows bash.exe defaults/properties... ctrl+a is similarly ignored for remote byobu+screen sessions :-(


LOLFML: "showkey -a" produces NO output for ctrl+a presses.


@nuclearmistake You are right, just notice is not a problem of ConEmu. Just ignore it...


aye. neither was the vim stuff though LOL. - seems the vim arrow-handling is weird in the same way cygwin's is.
Anyways: ctrl+a issue = Microsoft/BashOnWindows#156


Thanks for the feedback. Support for Ctrl+A has been fixed in the code, but the build is not yet publicly available through flighting. No ETA on when that will be available, sorry.


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

Help for bash, but doesn't work in mc


If that issue occurs in both conemu and vanilla windows bash, open a ticket on . there may be a way to work around it through MC's configuration facilities


mc in "vanilla windows bash" works without problems with arrow keys
EDIT: Doesn't work in "vanilla windows bash" also after more testing Microsoft/BashOnWindows#26


I noticed the function keys (F10, etc.) are working in mc after setting -cur_console:p1, but as @KindDragon said, not the arrow keys.


I suppose that mc, same as vim, requests DECCKM mode, but ConEmu has no chance to know that.
Well, I'll make another workaround to give user ability to switch keyboard mode manually...
Really weird, because with cygwin or on native linux terminals, this change is done automatically. But in the current Windows release there is no way to do that.


-cur_console:p1 works for bash, but vim beeps and prints nothing (but nano works!)


It does not look like handy solution due to hotkey limitation.
If there is a way to force vim to understand, for example, \e[A instead of expected \eOA for UpArrow, it would be handy.

@Maximus5 Maximus5 added a commit that referenced this issue Apr 13, 2016
@Maximus5 GuiMacro: TermMode(<Mode>[,<Action>])
  Ref gh-629: To β€˜fix’ arrow keys in vim in bash on Ubuntu on Windows
  one may set hotkey for macro `TermMode(2)` and switch keyboard mode
  manually when vim (linux process) is started and exited.

  - changes active terminal modes
    Mode==0: Keyboard emulation (Xterm/Windows)
    Mode==1: Bracketed paste
    Mode==2: Application cursor keys (DECCKM)
    Action==0: Disable mode
    Action==1: Enable mode
    Action==2: Switch mode (default)

Hey @nuclearmistake, I'm having some trouble implementing the fix you've suggested -- I keep getting a error akin to "Error detected while processing /root/.vimrc:
line 4:
E518: Unknown option: ,"

Anyone else having this problem/anyone have suggestions? I've been barking up this tree all day today without making much progress.


You need to literally "press Ctrl+v", then " press the appropriate arrow key" on each line. (Ctrl+v, ___ arrow) are the steps for inserting the magic character for the ____ arrow key.


@nuclearmistake that worked!!! Thank you so much, my god. Really appreciate it!!!


Generally I dislike chords of keys when simpler solution exists.

Update to 160416, it's expected to be working properly. Just fix your existing task.


@Maximus5 Just updated to 160416. Task starting with: %windir%\system32\bash.exe -cur_console:p works well for both bash and vi. (without @nuclearmistake 's workaround, and no need to do manual switch)
Is that what you mean as a final solution? It feels great!


I suppose it's a final workaround for the current insider build.

We have absolutely no idea, what may be changed in the next insider build...

@Maximus5 Maximus5 closed this Apr 17, 2016

just say thanks for quick fix

@Maximus5 Maximus5 added the other-wsl label May 10, 2016

@nuclearmistake This works! i think you should add it to the wiki page. for the sake of clarity.

fredrikaverpil commented May 17, 2016 edited

Not sure what I'm doing wrong. I have ConEmu 160504 and I run %windir%\system32\bash.exe -cur_console:p1 to enter the Linux subsystem bash. In the ConEmu settings I've set "Paste mode 2" to "Do nothing".

Arrow keys are working fine (in e.g. nano), but not in vim. When in "insert" mode and I hit the arrow keys, nothing happens. I can use the hjkl keys in "command" mode as a workaround.

So I followed the wiki instructions and edited .bashrc and .vimrc. Still no arrow keys in vim. What am I missing?


Does vim works in Bash4Windows started outside of ConEmu? Have you set xterm for vim term? Have you even change proper vimrc?
Anyway I have no ideas about vim. Its code is complicated and configuration is entangled.


Also, the wiki page is obsolete, has no use in current ConEmu build, and most probably have to be deleted.
Browse official website for vim related issues.


Does vim works in Bash4Windows started outside of ConEmu?

Yes. And arrow keys works fine when running vim in the Microsoft-bundled "Bash on Ubuntu on Windows" console. I'm only have this issue when using ConEmu.

Have you set xterm for vim term?

In bash, echo $TERM yields xterm. But I don't have this set explicitly in my .vimrc. I now tried setting set term=xterm in my .vimrc but that didn't make any difference.

Have you even change proper vimrc?

Not sure what you mean. I've started out from an empty .vimrc and entered stuff one by one. Never have the arrow keys worked when using the vim/Bash4Windows/ConEmu combo, regardless of the .vimrc contents.


Not sure what you mean. I've started out from an empty .vimrc

What does :echo $MYVIMRC print? Anyway, what did you entered in vimrc? It runs from the box.

fredrikaverpil commented May 18, 2016 edited

What does :echo $MYVIMRC print?

That points to my .vimrc: /home/fredrik/.vimrc.

Anyway, what did you entered in vimrc?

It's completely empty, to make it easier to find what's causing this.

I realized just now, that when I'm in vim's "insert" mode and I hit any of the arrow keys, I'm taken out of "insert" mode and into "command" mode. So basically, the arrow keys do the same thing as the Esc key.
That's strange!


Not so strange, the arrow keys send a sequence that starts with 0x1B (ASCII ESC).
Vim doesn't seem to recognise the sequence as one, hence it acts on each byte separately.


FWIW, I just noticed the same problem affecting winpty (rprichard/winpty#82). It looks like there's a new (undocumented) console input mode flag, 0x200. When it's enabled, and when certain keys are pressed down, the console generates an escape sequence (encoded as multiple key event records) rather than generate a single bKeyDown=TRUE event record. The bKeyDown=FALSE record is generated normally, as before.

Maximus5 commented Jun 5, 2016

@rprichard Ah, I see, bash sets 0x200 flag when it starts. Thanks for the hint

musm commented Jul 8, 2016

Is it possible to get 256 colors as well?

Maximus5 commented Jul 8, 2016

Is it possible to get 256 colors as well?

It's off-topic in the issue. Anyway, you should ask Microsoft to change the implementation:

hello-jason commented Jul 23, 2016 edited

I have arrow keys working with the following settings on a new task. Also, I'm using the mini version of cmder.

Task parameters:

/icon "%USERPROFILE%\AppData\Local\lxss\bash.ico"


%WINDIR%\System32\bash.exe ~



My previous task setup worked for some time, then it did not.

I'm not sure why this issue is closed. It is not resolved.


My previous task setup worked for some time, then it did not.

I'm not sure why this issue is closed. It is not resolved.

@hello-jason I downloaded the lastest version of Cmder and applied your solution which enables me to use arrow keys in bash.exe, but not vim (nano works).

Ehekatl commented Aug 8, 2016

I got arrow key working on latest relaese, with task defination

>*%SYSTEMROOT%\System32\bash.exe -c zsh -new_console:a:s:p:n

but sometimes the arrowkey won't work and output wired stuff


ctrl + c could fix it, but why ?

mstormo commented Aug 10, 2016

@Maximus5 I see your commit gh-629, however, the problem is not just with the Bash process. For example, running the new docker integration, you'll have the exact same issue in those bash variants. So I suggest you do a more general fix, than a fix which does explicit gbIsBashProcess checking.

Shouldn't the work around be done for all processes which use the new 0x200 undocumented input flag?

Or at least some way of being able to manually set the override on a given console task/tab.


tested the workaround and it looks good, except when running TMUX
when splitting a window into multiple panels, the escape sequence with arrows to move between panels won't work but it will just give output:
up arrow --> OA
down arrow --> OB


When WSL bypassed ANSI to ConEmu, than ConEmu would be able to change keyboard mode.
I see no sense in discussing the problem at the moment.

insight1111 commented Aug 17, 2016 edited

Ehekatl thanks so much!
I get workaround too.I set %SYSTEMROOT%\System32\bash.exe -new_console:a:p:n
(I can't use zsh and I won't use split window...)
In vim and nano recognize cursor key.

sevir commented Aug 17, 2016

Working with this simple configuration:

  • Task parameters
/icon "%USERPROFILE%\AppData\Local\lxss\bash.ico"
  • Commands
C:\windows\system32\bash.exe -l -i -cur_console:p1 -new_console:p:n

@insight1111 thanks for your workaround πŸ‘


Unfortunately I stopped using ConEmu because of this issue. Workaround doesn't work in my case (with git bash).


Workaround doesn't work in my case (with git bash).

This issue not about bash that included in Git for Windows


This issue not about bash that included in Git for Windows

Maybe it is not, but I get exactly the same issue in bash and not in normal command line inside ConEmu.


ConEmu implemented xterm keys emulation long-long ago. When ConEmu detects the flag 0x200 in console, xterm is turned on automatically.

To check, one may do simple steps:

  1. Run ConEmu64.exe -basic -run {bash}.
  2. Reveal StatusBar column Terminal modes and ensure it shows XA.
  3. Execute in started bash prompt few commands like cd ~ and ls -a.
  4. Try arrow keys, history and navigation are expected to be working.

I get invalid switch specified -run. Can you show an example please? Or what can I add to ConEmu to add it as new console (bash with working cursor keys).


@borgdrone7 are you sure you are running actual ConEmu version? Old Builds

The command line provided above is the working example. It runs ConEmu 64bit GUI with working Bash from WSL inside.


Thanks, I will update to the latest version and try again.

SowingSadness commented Nov 8, 2016 edited

@borgdrone7 try to
bash -cur_console:p
without "1"


I stopped using conemu a while back because I couldn't get arrow keys to work in vim (bash on Windows) and decided to return today to give it another go. Still doesn't work for me out of the box with a fresh install of conemu 64-bit + vim in bash.

The arrow keys work fine in bash itself, and in other editors such as nano. But when in vim, I can't move around using the arrow keys. Am I the only one experiencing this?


@fredrikaverpil In my test it only works if I run the {bash} task. It does not work by running bash -cur_console:p from cmd.


Up/Down arrow keys don't work as expected in FAR Manager. When panels are hidden, they are supposed to browse through command history, but now they have no effect. They move the cursor in panels when panels are shown though.

Maximus5 commented Dec 5, 2016 edited

Why have you posted the problem of native Windows application (which Far is) in the issue about Linux subsystem?
Anyway, I'm not a Far author, therefore can't accept Far Manager bug reports.


How would I figure out this is an issue about Linux when it is called "Arrow keys not working in Bash for Windows"?
Also, this is not a FAR issue. Arrow keys stopped working as expected after ConEmu update.


How Bash for Windows related with Far?


Apparently, the symptoms are the same under ConEmu - that's how

Maximus5 commented Dec 6, 2016

@kerabromsmu FYI arrows are working as expected with Far Manager. Regards of ConEmu version.


Just updated to the newest version of ConEmu, and the problem still persists with Far 3.0 4774. Updated Far to the last nightly build. No change in behavior. Tried to run Far without plugins - no change.

Maximus5 commented Dec 7, 2016

@kerabromsmu I've said already:

  1. Don't post Far Manager problems (which is native Windows application) in the issue about Linux subsustem!
  2. Arrow keys are working properly in Far. Especially for you just tested ConEmu 161203 + Far 4774.
  3. Read this:

I use ConEmu 161206[64]

Maximus5 commented Dec 8, 2016

@kerabromsmu It does not matter, because you are bombing me since previous build. Please read my messages, stop post offtopic, and explain (to yourself at least) why do you think that the problem is with ConEmu.

KindDragon commented Dec 8, 2016 edited

@kerabromsmu uninstall ConEmu and try Far without it


Sorry, I didn't mean to be rude. Tried Far without ConEmu. Arrows still work wrong. Tried removing all the plugins. Still no effect. But. Arrows worked perfectly before updating ConEmu with the same version of Far, and they stopped working after updating ConEmu a few days ago. Also, you say that arrows work correctly in Far for you. So perhaps I was wrong or perhaps the update permanently changed something on my system. Looks like some exotic case to me.

Maximus5 commented Dec 9, 2016

ConEmu installer/updater never changes any files of third-party programs.
All off-topic would be cleaned from the issue...


Build 161206
I'm starting Bash with the command %windir%\system32\bash.exe -cur_console:p1 but the problem is still there.


bash.exe -cur_console:p
without 1 - fix the problem for me! Thanks guys! Special thanks to @Maximus5 for developing the best terminal for windows


Sadly, I'm still running into this issue even with setting -cur_console:p1 or with -cur_console:p. I've always reopened whole ConEmu. Using 170118.


@lordgreg hard to believe

  1. Press Win+R
  2. Type in the dialog ConEmu64.exe -basic -run {bash}
  3. Check arrows


You are right, I'm sorry. Next time I should open the file that doesn't have just newline in first line and try to press right. -.-

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment