Can not use docker.exe to run interactive docker containers from inside WSL, can not use arrow keys inside docker-compose.exe run containers

[veqryn]

Can not use docker.exe to run interactive docker containers from inside WSL, can not use arrow keys inside docker-compose.exe run containers.

• Your Windows build number: Microsoft Windows [Version 10.0.15063]

• What you're doing and what's happening:
  From inside WSL Bash:

02:42:50 ~$ which docker.exe
/mnt/c/Program Files/Docker/Docker/resources/bin/docker.exe
02:42:56 ~$ docker.exe --version
Docker version 17.06.0-ce, build 02c1d87

02:44:33 ~$ docker.exe run -it ubuntu:16.04 /bin/bash
the input device is not a TTY.  If you are using mintty, try prefixing the command with 'winpty'
02:45:16 ~$ winpty docker.exe run -it ubuntu:16.04 /bin/bash
winpty: command not found

02:46:01 ~$ cmd.exe /c chcp 437
Active code page: 437
02:46:56 ~$ docker-compose.exe --version
docker-compose version 1.14.0, build c7bdf9e3
02:47:14 ~$ docker-compose.exe run my-ubuntu /bin/bash
Starting my-ubuntu ... done
bash-4.2#

bash-4.2#

bash-4.2# pwd
pwd
/
bash-4.2# ^[[A^[[A^[[B^[[A

That last line is me hitting the UP-Arrow key, expecting to see pwd fill my command prompt, but instead getting a bunch of ^[[A^[[A^[[B^[[A

• What's wrong / what should be happening instead:

I would expect that I could use the native windows docker.exe to run interactive containers and also exec into containers.
I'm not sure why docker.exe complains but docker-compose.exe does not complain.

I would also expect that docker-compose run (interactively) would behavior normally, instead of printing out all my commands, extra line returns, and not letting me use the UP-Arrow to navigate previous commands.

I had greatly hoped to be able to use the windows docker executables already installed on my system.

Instead, in order to get my desired behavior, I had to install the linux docker executables into WSL, and then expose the Docker Daemon TCP Host on localhost (which is a security issue!), and then point the linux docker executables at it (ie: the way people did docker in wsl before the creator's update).

[fpqc]

@veqryn This is a docker.exe issue, I believe. It is not aware of the new console functionality and probably duplicates it to some degree. We saw similar problems on Win32-OpenSSH. Basically, when compiling docker.exe, they need to flip a few console flags up on the IO handles and disable their built-in terminal emulation code to allow the Windows console to take over processing.

This is some related documentation:

https://msdn.microsoft.com/en-us/library/windows/desktop/mt638032(v=vs.85).aspx

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686033(v=vs.85).aspx
(see ENABLE_VIRTUAL_TERMINAL_xxxxxx mode flags)

Right now, I believe even if they do enable this, there might still be some bugs, since vt ctlseq processing functionality is incomplete in a few areas and buggy in others (look at the console tag on here).

On the other hand, is there any reason why you're using docker.exe instead of the Linux docker-client executable? That should be able to connect to the hyper-v docker container host or a remote linux docker host just as well as docker.exe.

[veqryn]

The main reason is because i so not want to open my local laptop ports up, as it is a security issue.
Everything is local, so why not do it this way.

[fpqc]

@veqryn Pretty sure you don't need to open any ports to the outside world if the hyper-v virtual switch is a private switch rather than a shared switch that allows internet connectivity. You could even add another virtual switch and network adapter to the VM, make that private, and open the control port on the adapter connected to the private switch only, allowing local control and also firewalled access to the internet.

Edit: Ah, it looks like you ended up doing something like this.

[veqryn]

So, I'm mostly basing my opinion off the fact that I have to go into Docker for Windows settings, then click the checkbox that reads:

Expose daemon on tcp://localhost:2375 without TLS
Exposing daemon on TCP without TLS helps legacy clients connect to the daemon.
It also makes yourself vulnerable to remote code execution attacks. Use with caution.

That sounds pretty scary, right?

Docker for Windows creates an "internal" network switch in hyperv, but I'm not exactly sure how the docker.exe client on the windows host communicates with the docker server running in hyperv.
If it communicates using that switch, then presumably I should also be able to connect through that switch without "exposing the daemon". I'm also not sure if that would be any different than exposing the daemon.
If it communicates using windows comms or something else, then sol.

[fpqc]

It communicates by IP. This has been the recommended method from WSL for ages. Hyper-V VMs run in full hypervisor-level isolation. Pretty sure a non-IP method of communication would be pretty bad. Also, since docker-client communications don't need high levels of bandwidth or ultra-low latency, it makes like no sense to create a de novo communication interface.

[veqryn]

Well, I've tried connecting telling the docker client to connect to 10.0.75.0:2375 (the IP of the internal virtual switch's ip), but no luck.
If you know a better way then clicking that "expose daemon (make yourself vulnerable)" checkbox, please let me know...

[raupie]

What about exposing the port and then setting up a firewall rule?

Getting the same the input device is not a TTY error. Really frustrating as there is very little documentation on how to fix this.

[therealkenc]

Getting the same the input device is not a TTY error.

That's #2406

[waleedka]

Is there any planned fix for this issue? Can someone share an update?

[zlyuk13]

Got this issue on one of the PCs. Assuming that everyone would have Git installed I would suggest when prompted during the step Configure the terminal emulator to use with Git Bash select a second option Use Windows default console window

[therealkenc]

The OP submission here was:

02:44:33 ~$ docker.exe run -it ubuntu:16.04 /bin/bash
the input device is not a TTY. If you are using mintty, try prefixing the command with 'winpty'

Appears to be okay on WSL2 with Windows Terminal. It was not reproduced locally back in 2017.

There was were no repro steps for the docker-compose.exe scenario, but those ^[[A^[[A^[[B^[[A looks like linux-behavior. Open a discussion to track that further if you like, on a chance it can be turned into an actionable.