Conemu: 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 https://github.com/Maximus5/ConEmu/issues/183 and https://github.com/docker/docker/issues/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.

[SelaliAdobor]

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!

[SelaliAdobor]

thread from the last time people had this issue

referred to https://github.com/Maximus5/ConEmu/issues/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.

[SelaliAdobor]

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.

[lemourin]

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

[gazben]

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

[nuclearmistake]

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]

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]

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]

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

[ycrichard]

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

[nuclearmistake]

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 = https://github.com/Microsoft/BashOnWindows/issues/156

[sunilmut]

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]

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

Help for bash, but doesn't work in mc

[nuclearmistake]

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

[KindDragon]

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

[scovetta]

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

[Maximus5]

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.

[mainnika]

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

[Maximus5]

@mainnika https://github.com/Maximus5/ConEmu/issues/629#issuecomment-209482472

[nuclearmistake]

@Maximus5 @mainnika I've centralized the work-around on a wiki page: https://github.com/Maximus5/ConEmu/wiki/Bash-For-Windows-and-VIM-Arrow-Keys

[Maximus5]

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.

[peterdolan]

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.

[nuclearmistake]

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.

[peterdolan]

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

[Maximus5]

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.

[ycrichard]

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

[Maximus5]

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

[helloyan]

just say thanks for quick fix

[KindDragon]

JFI https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/

[omerbenamram]

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

[fredrikaverpil]

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?

[Maximus5]

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.

[Maximus5]

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.

[fredrikaverpil]

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.

[Maximus5]

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]

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!

[xylographe]

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.

[Maximus5]

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

[rprichard]

FWIW, I just noticed the same problem affecting winpty (https://github.com/rprichard/winpty/issues/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]

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

[musm]

Is it possible to get 256 colors as well?

[Maximus5]

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:
https://github.com/Microsoft/BashOnWindows/issues/406

[hello-jason]

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"

Commands:

%WINDIR%\System32\bash.exe ~

[hello-jason]

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.

[kleinfreund]

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]

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

^[OA^C
^[OA^[OA^[OD^[OC^[OD^[OB^[

ctrl + c could fix it, but why ?

[mstormo]

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

[elfosardo]

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

[Maximus5]

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]

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]

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 👍

[borgdrone7]

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

[KindDragon]

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

This issue not about bash that included in Git for Windows

[borgdrone7]

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.

[Maximus5]

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.

[borgdrone7]

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

[Maximus5]

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

[borgdrone7]

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

[SowingSadness]

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

[fredrikaverpil]

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?

[camsteffen]

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

[kerabromsmu]

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]

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.

[kerabromsmu]

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.

[KindDragon]

How Bash for Windows related with Far?

[kerabromsmu]

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

[Maximus5]

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

[kerabromsmu]

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]

@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: https://conemu.github.io/en/BadIssue.html

[kerabromsmu]

I use ConEmu 161206[64]

[Maximus5]

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

@kerabromsmu uninstall ConEmu and try Far without it

[kerabromsmu]

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]

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

[nikolaikopernik]

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

[nikolaikopernik]

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

[lordgreg]

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.

[Maximus5]

@lordgreg hard to believe

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

[lordgreg]

@Maximus5

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

[hell0world]

-cur_console:p1 works fine with conemu-connector.thx your guys

[windhamwong]

None of the solution works for me.
However, Ctrl+B = Up and Ctrl+N = Down.
I am still looking for a good solution. I want to press ArrowUp to get back my previous command in bash as well..

$ bash --version
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)

[rmoro]

I have the exact same issue but it seems that the arrow keys for bash do not work in a standard windows command prompt and if you are using a terminal emulator like cmder the problem will occur if you select a regular command prompt.

to fix the issue just open bash in a power shell prompt. (or an emulated powershell prompt)

[origintopleft]

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.

[SeriousM]

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]

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 https://github.com/cmderdev/cmder/issues/1312#issuecomment-294630922

[richard-scott]

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]

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]

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

[jonathanlxy]

(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

[EwolBash]

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

[Maximus5]

@Esux Your message is obscure.

[diveyez]

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

[diveyez]

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]

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

[diveyez]

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

[diveyez]

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

[Maximus5]

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

[chx]

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]

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

[chx]

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]

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 https://github.com/Maximus5/ConEmu/issues/2035

[asuiu]

-new_console:p5 fixed the issue for me.