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 · 143 comments

Comments

Projects
None yet
@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

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Apr 7, 2016

Owner

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.

Owner

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

This comment has been minimized.

Show comment
Hide comment
@Ordspilleren

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

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

This comment has been minimized.

Show comment
Hide comment
@reflog

reflog Apr 7, 2016

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

I wonder if it's related?

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

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Apr 7, 2016

Owner

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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@nuclearmistake

nuclearmistake 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

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

This comment has been minimized.

Show comment
Hide comment
@lennylxx

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

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

This comment has been minimized.

Show comment
Hide comment
@Ordspilleren

Ordspilleren 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 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

This comment has been minimized.

Show comment
Hide comment
@lennylxx

lennylxx 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'.

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

This comment has been minimized.

Show comment
Hide comment
@watzon

watzon Apr 8, 2016

I'm also having this issue

watzon commented Apr 8, 2016

I'm also having this issue

@pandada8

This comment has been minimized.

Show comment
Hide comment
@pandada8

pandada8 Apr 8, 2016

btw, all readline features also not working

pandada8 commented Apr 8, 2016

btw, all readline features also not working

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Apr 8, 2016

Owner

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

Owner

Maximus5 commented Apr 8, 2016

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

@alexleonard

This comment has been minimized.

Show comment
Hide comment
@alexleonard

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

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

This comment has been minimized.

Show comment
Hide comment
@Hooter

Hooter Apr 9, 2016

And do not work Function keys (F1-F12)

Hooter commented Apr 9, 2016

And do not work Function keys (F1-F12)

@ivanarnold

This comment has been minimized.

Show comment
Hide comment
@ivanarnold

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

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

This comment has been minimized.

Show comment
Hide comment
@SelaliAdobor

SelaliAdobor 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

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

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Apr 10, 2016

Owner

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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@SelaliAdobor

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

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

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Apr 11, 2016

Owner

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.

Owner

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

This comment has been minimized.

Show comment
Hide comment
@SelaliAdobor

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

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

gh-629: Support xterm keyboard emulation for ‘Bash on Ubuntu on Wind…
…ows’.

  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

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Apr 12, 2016

Owner

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

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

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

This comment has been minimized.

Show comment
Hide comment
@interpeix

interpeix Apr 12, 2016

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

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

@KayLeung

This comment has been minimized.

Show comment
Hide comment
@KayLeung

KayLeung Apr 12, 2016

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

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

@interpeix

This comment has been minimized.

Show comment
Hide comment
@interpeix

interpeix Apr 12, 2016

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

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

@Ordspilleren

This comment has been minimized.

Show comment
Hide comment
@Ordspilleren

Ordspilleren 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 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

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Apr 12, 2016

Owner

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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Apr 12, 2016

Owner

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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@Ordspilleren

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

@lemourin

This comment has been minimized.

Show comment
Hide comment
@lemourin

lemourin Apr 12, 2016

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

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

@gazben

This comment has been minimized.

Show comment
Hide comment
@gazben

gazben Apr 12, 2016

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

gazben commented Apr 12, 2016

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

@nuclearmistake

This comment has been minimized.

Show comment
Hide comment
@nuclearmistake

nuclearmistake Apr 12, 2016

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
fi
if [ $WINDOWS10 ]; then
  export LC_WINDOWS10=$WINDOWS10
fi

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

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.

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
fi
if [ $WINDOWS10 ]; then
  export LC_WINDOWS10=$WINDOWS10
fi

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

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.

@ycrichard

This comment has been minimized.

Show comment
Hide comment
@ycrichard

ycrichard Apr 12, 2016

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?

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?

@nuclearmistake

This comment has been minimized.

Show comment
Hide comment
@nuclearmistake

nuclearmistake Apr 12, 2016

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

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

@nuclearmistake

This comment has been minimized.

Show comment
Hide comment
@nuclearmistake

nuclearmistake Apr 12, 2016

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

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

@ycrichard

This comment has been minimized.

Show comment
Hide comment
@ycrichard

ycrichard Apr 12, 2016

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

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

@nuclearmistake

This comment has been minimized.

Show comment
Hide comment
@nuclearmistake

nuclearmistake Apr 12, 2016

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/WSL#156

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/WSL#156

@sunilmut

This comment has been minimized.

Show comment
Hide comment
@sunilmut

sunilmut Apr 12, 2016

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.

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.

@KindDragon

This comment has been minimized.

Show comment
Hide comment
@KindDragon

KindDragon Apr 12, 2016

Contributor

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

Help for bash, but doesn't work in mc

Contributor

KindDragon commented Apr 12, 2016

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

Help for bash, but doesn't work in mc

@SeriousM

This comment has been minimized.

Show comment
Hide comment
@SeriousM

SeriousM May 17, 2017

Hello from ConEmu 161206 on Windows 10 1703.

%windir%\system32\bash.exe ~ -c "zsh -l" -cur_console:p works perfectly fine in my "bash" task (which actually launches a zsh shell). arrow keys work fine in vim and the shell, no workarounds required.

I can confirm that this works without any problems and without any workarounds. Just add the task and execute/open it. Of course, install (oh-my-)zsh first.

Hello from ConEmu 161206 on Windows 10 1703.

%windir%\system32\bash.exe ~ -c "zsh -l" -cur_console:p works perfectly fine in my "bash" task (which actually launches a zsh shell). arrow keys work fine in vim and the shell, no workarounds required.

I can confirm that this works without any problems and without any workarounds. Just add the task and execute/open it. Of course, install (oh-my-)zsh first.

@Yoshi9143

This comment has been minimized.

Show comment
Hide comment
@Yoshi9143

Yoshi9143 Jul 6, 2017

I can confirm it works as well @lavacano201014 . I also had to restart ConEMU once I installed zsh. For those troubleshooting even after a restart, press the green "+" and see if it works there. If so, follow cmderdev/cmder#1312 (comment)

I can confirm it works as well @lavacano201014 . I also had to restart ConEMU once I installed zsh. For those troubleshooting even after a restart, press the green "+" and see if it works there. If so, follow cmderdev/cmder#1312 (comment)

@richard-scott

This comment has been minimized.

Show comment
Hide comment
@richard-scott

richard-scott Sep 20, 2017

I've just downloaded the latest Alpha 170910[64] and I still had the issues described on this ticket.
Thanks to this discussion, I've been able to find what I hope is my fix for this issue.

I have created a new default task with this command:

%windir%\system32\bash.exe ~ -c "bash -l" -cur_console:pm:/mnt

It seems to work OK so far for me, before (with the other shell task) I could reproduce my issue consistently if I edited a long text file in nano and moved about in it. So far, no issues so I still get all the lovely features of Bash, but without the limitation of cursor presses inserting random A (or B) letters or blanking out parts of the screen.

I've just downloaded the latest Alpha 170910[64] and I still had the issues described on this ticket.
Thanks to this discussion, I've been able to find what I hope is my fix for this issue.

I have created a new default task with this command:

%windir%\system32\bash.exe ~ -c "bash -l" -cur_console:pm:/mnt

It seems to work OK so far for me, before (with the other shell task) I could reproduce my issue consistently if I edited a long text file in nano and moved about in it. So far, no issues so I still get all the lovely features of Bash, but without the limitation of cursor presses inserting random A (or B) letters or blanking out parts of the screen.

@Aldans

This comment has been minimized.

Show comment
Hide comment
@Aldans

Aldans Sep 27, 2017

win10, conemu 170807, git bash (_https://git-scm.com/) The cursor does not select menu items but prints the characters https://prnt.sc/gqietn

Aldans commented Sep 27, 2017

win10, conemu 170807, git bash (_https://git-scm.com/) The cursor does not select menu items but prints the characters https://prnt.sc/gqietn

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Sep 27, 2017

Owner

@Aldans Why do you post git-bash problem in WSL topic? Anyway, your description is unclear.

Owner

Maximus5 commented Sep 27, 2017

@Aldans Why do you post git-bash problem in WSL topic? Anyway, your description is unclear.

@jonathanlxy

This comment has been minimized.

Show comment
Hide comment
@jonathanlxy

jonathanlxy Oct 4, 2017

(I know this comment might look silly, but I have spent 2 days trying to figure out how to setup bash.exe -cur_console:p in Cmder. So I think sharing it here would help someone who is not familiar with ConEmu)

If you want to have WSL bash (with arrow keys issue fixed) as default when Cmder is opened, do the following:

  1. Create a task called whatever you like, e.g. {bash}, in Settings--Tasks, with command %windir%\system32\bash.exe -cur_console:p
  2. In Settings--Startup, select the task you just created as "Specified named task"
  3. Save settings, now every time you open Cmder, it automatically runs bash.exe -cur_console:p for you

(I know this comment might look silly, but I have spent 2 days trying to figure out how to setup bash.exe -cur_console:p in Cmder. So I think sharing it here would help someone who is not familiar with ConEmu)

If you want to have WSL bash (with arrow keys issue fixed) as default when Cmder is opened, do the following:

  1. Create a task called whatever you like, e.g. {bash}, in Settings--Tasks, with command %windir%\system32\bash.exe -cur_console:p
  2. In Settings--Startup, select the task you just created as "Specified named task"
  3. Save settings, now every time you open Cmder, it automatically runs bash.exe -cur_console:p for you
@Esux

This comment has been minimized.

Show comment
Hide comment
@Esux

Esux Feb 24, 2018

I can get the arrow keys to work using some of the above suggestions, but can't press ENTER to change values.

Esux commented Feb 24, 2018

I can get the arrow keys to work using some of the above suggestions, but can't press ENTER to change values.

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Mar 8, 2018

Owner

@Esux Your message is obscure.

Owner

Maximus5 commented Mar 8, 2018

@Esux Your message is obscure.

@diveyez

This comment has been minimized.

Show comment
Hide comment
@diveyez

diveyez Mar 23, 2018

Still having this issue. Randomly after months of working fine. IT CAME BACK.

diveyez commented Mar 23, 2018

Still having this issue. Randomly after months of working fine. IT CAME BACK.

@diveyez

This comment has been minimized.

Show comment
Hide comment
@diveyez

diveyez Mar 23, 2018

To fix this, Add -cur_console:p to the end of default task
Thats the only way, as WSL now has distro switcher built in

diveyez commented Mar 23, 2018

To fix this, Add -cur_console:p to the end of default task
Thats the only way, as WSL now has distro switcher built in

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@diveyez

This comment has been minimized.

Show comment
Hide comment
@diveyez

diveyez Apr 3, 2018

None of that works now, since Microsoft really screwed up the WSL distros

diveyez commented Apr 3, 2018

None of that works now, since Microsoft really screwed up the WSL distros

@diveyez

This comment has been minimized.

Show comment
Hide comment
@diveyez

diveyez Apr 3, 2018

I have no way to change terminal mode to xterm following solution 2, bad instructions

diveyez commented Apr 3, 2018

I have no way to change terminal mode to xterm following solution 2, bad instructions

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Apr 3, 2018

Owner

@diveyez Keys are working in ConEmu from the box. You have not described what have you tried and where was the problem.

Owner

Maximus5 commented Apr 3, 2018

@diveyez Keys are working in ConEmu from the box. You have not described what have you tried and where was the problem.

@chx

This comment has been minimized.

Show comment
Hide comment
@chx

chx Apr 13, 2018

Arrows do not work in iex, the interactive Elixir shell. Also ^w deletes the entire line in MySQL instead of just one word as it does in shell (although the latter is fixable https://unix.stackexchange.com/a/253178/9452 )

chx commented Apr 13, 2018

Arrows do not work in iex, the interactive Elixir shell. Also ^w deletes the entire line in MySQL instead of just one word as it does in shell (although the latter is fixable https://unix.stackexchange.com/a/253178/9452 )

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Apr 14, 2018

Owner

@chx Why do you post their problems here?
Third-party application problems

Owner

Maximus5 commented Apr 14, 2018

@chx Why do you post their problems here?
Third-party application problems

@chx

This comment has been minimized.

Show comment
Hide comment
@chx

chx Apr 14, 2018

These are broken because of the WSL+Conemu combo and this issue is about arrow keys and WSL? Should I open a new issue?

chx commented Apr 14, 2018

These are broken because of the WSL+Conemu combo and this issue is about arrow keys and WSL? Should I open a new issue?

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Apr 14, 2018

Owner

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

Owner

Maximus5 commented Apr 14, 2018

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

@chx

This comment has been minimized.

Show comment
Hide comment
@chx

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

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

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Apr 14, 2018

Owner

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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@chx

chx 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 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

This comment has been minimized.

Show comment
Hide comment
@chx

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

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

This comment has been minimized.

Show comment
Hide comment
Owner

Maximus5 commented Apr 14, 2018

@chx

This comment has been minimized.

Show comment
Hide comment
@chx

chx Apr 14, 2018

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

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

This comment has been minimized.

Show comment
Hide comment
@rahar

rahar May 24, 2018

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

rahar commented May 24, 2018

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

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 May 24, 2018

Owner

Run default task for your shell

Owner

Maximus5 commented May 24, 2018

Run default task for your shell

@elijahgagne

This comment has been minimized.

Show comment
Hide comment
@elijahgagne

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

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

This comment has been minimized.

Show comment
Hide comment
@rahar

rahar May 24, 2018

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

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

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 May 24, 2018

Owner

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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@yellow-sock

yellow-sock 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!

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

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Jul 18, 2018

Owner

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

ConEmu64.exe -basic -run {bash}

I doubt you have tried it

Owner

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

This comment has been minimized.

Show comment
Hide comment
@yellow-sock

yellow-sock 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 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

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Jul 18, 2018

Owner

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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@lucaswunder

lucaswunder Jul 21, 2018

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

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

@PeterFogh

This comment has been minimized.

Show comment
Hide comment
@PeterFogh

PeterFogh 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

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

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