Conemu: arrow navigation doesn't work with 'docker run'

[tmds]

I am starting docker containers in conemu and I am unable to use the arrow keys. On the default windows terminal the arrow keys work fine.

There is a similar issue reporter on the docker project which is: arrow keys not working on the default windows terminal (https://github.com/docker/docker/issues/13817).

[Maximus5]

If this is a docker issue why do you report it here?

[tmds]

For me, it is working okay in the windows default terminal but not in ConEmu.

[Maximus5]

What does that mean: "unable to use the arrow keys"?

[tmds]

For example: If I am using bash and I have am typing a command, I cannot use the left key to change what I was typing before or the up key to go back into history.

[Maximus5]

And how exactly you are running bash in that case?

[tmds]

docker run --rm -ti debian:jessie /bin/bash

[phazei]

I'm coming across the same issue. I posted the original bug in docker/docker. I noticed @tmds mentioned it only happened in ConEmu and I tried it in a normal cmd, and I could use the keys.

I'm running docker run --rm -it --entrypoint=//bin/bash ubuntu:14.04

If I'm in cmd or bash with or without ConEmu and to a boot2docker ssh first to load into the vm first, it works fine.

If from ConEmu cmd or bash I run
docker.exe run --rm -it --entrypoint=//bin/bash ubuntu:14.04
I don't get arrow keys, or home/end/page up/page down.

[Maximus5]

I believe the key is that when you run "bash" in ConEmu tab you run it with mandatory switches -l -i. But I do not see them in your docker command.

[phazei]

Just tried docker.exe run --rm -it ubuntu:14.04 //bin/bash -l -i
with no effect.

[tmds]

@Maximus5, can you follow the issue in the docker repository (https://github.com/docker/docker/issues/13817)? Then we can all follow it up there.

[mtelesha]

I believe the issue is with conemu and doesn't communicate the terminal to the server. I had the same sort of issue with vagrant ssh. Git-Bash and cynwin both worked fine but conemu and cmder both had issues with arrow keys and backspace. ctl-shift + V + backspace gave the proper ^$.

My solution which returned full arrow navigation and backspace:

export TERM=vt100

Here is a quick screen cast of the bug and then behavior after the fix.

https://youtu.be/EtazaEPGQzk

[Maximus5]

@mtelesha If your _solution_ is working, the issue can't be with ConEmu at all. ConEmu do not relate to TERM variable. Never.

[mtelesha]

I don't have to do this with any other tool I use for ssh. Putty, Moba Xterm, git-bash, cygwin all work out of the box. If this is an SSH issue then none of them should work?

BTW I loved ConEmu and am really excited I can use it for ssh.

[Maximus5]

Putty and Moba Xterm - are remote terminals, they implement their own commucation protocols.
git-bash is not a terminal at all. It's a shell, which may be started in terminal.
cygwin is not a terminal too. It's a package of ported applications.
If you mean mintty, than it is a POSIX PTY emulator, it almost do not relate to Windows API.

Windows applications have to run properly in Windows, haven't they?
https://conemu.github.io/en/CygwinMsys.html

But ConEmu implements (actually reuses) real Windows console window. Absolutely the same behavior you'll see if you run your shell or ssh from Win+R.

How many times I have to say that, I wonder?
https://conemu.github.io/en/Delusions.html

[Maximus5]

In the other words, Putty and Moba Xterm are doing the same work, which actually ssh.exe have to do. But ssh.exe is doing this work not quite good.

[mtelesha]

I listed out TOOLS that I use with SSH that works (I didn't say that they were the same just I use SSH in Windows because I have to and these TOOLS work). You treated me like an ignorant child with your bold and "How Many Times I have to Say That."

ConEmu does NOT work with ssh into Vagrant or to SSH servers unless the user communicates their terminal with TERM or use stty. You could put this in FAQ or the README and then people would know how to get ConEmu and cmder to work in ssh, BUT I guess I wasted your time.

So this exchange has left a bitter taste in mouth (and I certainly won't be bothering you again.) Also guess you didn't look at my video to see the behavior and the change this was a SOLUTION for my issue with backspace and arrows but I wasted you and my time.

[Maximus5]

@mtelesha I took a look at your video. However it's not quite clear what was working and what wasn't.
As for your suggestion about solution and FAQ... ConEmu do not provide any remote features, right? User choose any tool for their taste. But this tool fails. Who is guilty? ConEmu? I do not think so.

If console application (which is ssh.exe) fails in standard Windows terminal (which ConEmu utilizes and extends in fact), I can make only one conclusion: something wrong with this console application. How about you?

Anyway, thanks for sharing your experience, it may help other users.

[mtelesha]

I'll make another video which also shows that arrows and backspace and delete work for SSH in Window's cmd, PowerShell and git-bash. When i use those inside ConEmu for some reason all those inside SSH my arrow, backspace and delete to not work as expected. ctl-shift + V then Backspace gives me ^$. When I echo TERM all keys work as expected again.

The video shows my keystrokes and what happens in Windows cmd. Backspace types a space in ConEmu but it actually still deletes on the SSH server side. Right arrow paste the prompt and up arrow does not go through my history.

[Maximus5]

You mentioned several times Ctrl-Shift-V, but that is not ConEmu default hotkey. What is it intended to do?

I'm not quite sure, what happens when you execute export ... on server side. The command is executed on server, yes?

Anyway, ConEmu do not change posting sequences when you execute export, so the problem may be inside used ssh client. But it would be interesting, what server receives?
Can you compile and run key-reader on your server and check what server receives on problematic keystrokes (arrows and BS, right)?

[tmds]

Close per https://github.com/docker/docker/issues/13817