Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arrow keys not working in Bash for Windows #629

Closed
Ordspilleren opened this issue Apr 6, 2016 · 151 comments
Closed

Arrow keys not working in Bash for Windows #629

Ordspilleren opened this issue Apr 6, 2016 · 151 comments

Comments

@Ordspilleren
Copy link

@Ordspilleren Ordspilleren commented Apr 6, 2016

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
Copy link
Owner

@Maximus5 Maximus5 commented Apr 7, 2016

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
Copy link
Author

@Ordspilleren Ordspilleren commented Apr 7, 2016

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
Copy link

@reflog 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
Copy link
Owner

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

@nuclearmistake
Copy link

@nuclearmistake nuclearmistake commented Apr 7, 2016

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
Copy link

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

@Ordspilleren
Copy link
Author

@Ordspilleren Ordspilleren commented Apr 8, 2016

@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
Copy link

@lennylxx 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
Copy link

@watzon watzon commented Apr 8, 2016

I'm also having this issue

@pandada8
Copy link

@pandada8 pandada8 commented Apr 8, 2016

btw, all readline features also not working

@Maximus5
Copy link
Owner

@Maximus5 Maximus5 commented Apr 8, 2016

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

@alexleonard
Copy link

@alexleonard alexleonard commented Apr 9, 2016

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
Copy link

@Hooter Hooter commented Apr 9, 2016

And do not work Function keys (F1-F12)

@ivanarnold
Copy link

@ivanarnold ivanarnold commented Apr 10, 2016

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.

@SelaliAdobor
Copy link

@SelaliAdobor SelaliAdobor commented Apr 10, 2016

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
Copy link
Owner

@Maximus5 Maximus5 commented Apr 10, 2016

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

@SelaliAdobor
Copy link

@SelaliAdobor SelaliAdobor commented Apr 11, 2016

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
Copy link
Owner

@Maximus5 Maximus5 commented Apr 11, 2016

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.

@SelaliAdobor
Copy link

@SelaliAdobor SelaliAdobor commented Apr 11, 2016

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 added a commit that referenced this issue Apr 12, 2016
…ws’.

  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
@Maximus5
Copy link
Owner

@Maximus5 Maximus5 commented Apr 12, 2016

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

%windir%\system32\bash.exe -cur_console:p1
@interpeix
Copy link

@interpeix interpeix commented Apr 12, 2016

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

@KayLeung
Copy link

@KayLeung KayLeung commented Apr 12, 2016

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

@interpeix
Copy link

@interpeix interpeix commented Apr 12, 2016

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

@Ordspilleren
Copy link
Author

@Ordspilleren Ordspilleren commented Apr 12, 2016

@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
Copy link
Owner

@Maximus5 Maximus5 commented Apr 12, 2016

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
Copy link
Owner

@Maximus5 Maximus5 commented Apr 12, 2016

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

@Ordspilleren
Copy link
Author

@Ordspilleren Ordspilleren commented Apr 12, 2016

@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
Copy link
Owner

@Maximus5 Maximus5 commented Apr 14, 2018

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

@chx
Copy link

@chx chx commented Apr 14, 2018

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
Copy link
Owner

@Maximus5 Maximus5 commented Apr 14, 2018

@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
Copy link

@chx chx commented Apr 14, 2018

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
Copy link

@chx chx commented Apr 14, 2018

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
Copy link
Owner

@Maximus5 Maximus5 commented Apr 14, 2018

@chx
Copy link

@chx chx commented Apr 14, 2018

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

Maximus5 added a commit that referenced this issue Apr 16, 2018
@rahar
Copy link

@rahar rahar commented May 24, 2018

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

@Maximus5
Copy link
Owner

@Maximus5 Maximus5 commented May 24, 2018

Run default task for your shell

@elijahgagne
Copy link

@elijahgagne elijahgagne commented May 24, 2018

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
Copy link

@rahar rahar commented May 24, 2018

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

@Maximus5
Copy link
Owner

@Maximus5 Maximus5 commented May 24, 2018

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
Copy link

@yellow-sock yellow-sock commented Jul 17, 2018

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
Copy link
Owner

@Maximus5 Maximus5 commented Jul 18, 2018

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

ConEmu64.exe -basic -run {bash}

I doubt you have tried it

@yellow-sock
Copy link

@yellow-sock yellow-sock commented Jul 18, 2018

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

image

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

Something wrong with my installation ?

@Maximus5
Copy link
Owner

@Maximus5 Maximus5 commented Jul 18, 2018

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
Copy link

@lucaswunder lucaswunder commented Jul 21, 2018

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

@PeterFogh
Copy link

@PeterFogh PeterFogh commented Jul 25, 2018

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 added a commit to sunaku/home that referenced this issue Dec 5, 2018
@sunaku
Copy link

@sunaku sunaku commented Dec 5, 2018

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

@iam3fun
Copy link

@iam3fun iam3fun commented Oct 3, 2019

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

Thank you Lucas!

@calra123
Copy link

@calra123 calra123 commented Oct 23, 2019

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

@picorealm
Copy link

@picorealm picorealm commented Jan 15, 2020

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
Copy link

@ravermeister ravermeister commented Jan 15, 2020

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
Copy link

@danijeldomazetprivate danijeldomazetprivate commented Jan 22, 2020

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

@pccasto
Copy link

@pccasto pccasto commented Jan 26, 2020

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

@asuiu
Copy link

@asuiu asuiu commented Jun 24, 2020

-new_console:p5 fixed the issue for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.