Shell in container incrementally indents new lines

[cabdesigns]

Expected behavior

Normal formatting of terminal when using shell in any container.

Actual behavior

PS1/new lines appear to be incrementally indented.

Information

Docker for Mac: version: 17.06.0-rc1-ce-mac13 (4cdec4294a50b2233146b09469b49937dabdebdd)
macOS: version 10.11.6 (build: 15G1004)
logs: /tmp/F9B77585-F6F1-44E9-904C-849B7DF03E0A/20170601-130306.tar.gz
[OK]     db.git
[OK]     vmnetd
[OK]     dns
[OK]     driver.amd64-linux
[OK]     virtualization VT-X
[OK]     app
[OK]     moby
[OK]     system
[OK]     moby-syslog
[OK]     db
[OK]     env
[OK]     virtualization kern.hv_support
[OK]     slirp
[OK]     osxfs
[OK]     moby-console
[OK]     logs
[OK]     docker-cli
[OK]     menubar
[OK]     disk

Steps to reproduce the behavior

1. docker pull alpine
2. docker run -it alpine /bin/sh
3. Hit return a few times.

See output like below:

/ #
    / #
        / #
            / #
                / #
                    / #
                        / #

Discovered after updating to new edge release. Not alpine/sh specific. Also replicated on Debian derived images using bash. Also replicated on separate machine. Replicated on both Terminal and iTerm2.

[nuzz]

Annoying bug for sure. If you type reset it will fix the terminal output for that session. Looking forward for this to being hotfixed.

[jasonmccallister]

Attaching a screenshot for the TL;DR people (thought I was going crazy).

[KevinGimbel]

Can confirm this happens after updating to latest edge 17.06.0-rc1-ce-mac13 (18169) on MacOS 10.12.1. Was working the other day and this morning before I updated.

[o5]

Same here. It would be nice to have page with links to specific version of edge, fe docker for-mac github releases page. I found only two links in store with latest release for both of version. Locally downloaded DMG from the previous week saves me.

[42ae]

Same issue here with the Docker edge 17.06.0-ce-rc1, build 7f8486a on MacOS 10.10.5.

[eerootsus]

+1

[JamesRootNineAgile]

+1 and thanks @nuzz saved my sanity :)

[bradbeck]

+1

[ian-axelrod]

Typing reset didn't fix it for me, sadly.

[codercotton]

+1, reset doesn't fix for me, either.

[g0t4]

reset works for me, both Docker for Mac and Docker for Windows

[rfay]

stty sane also fixes.

[codercotton]

The reset command works inside the container - I was typing reset before entering the container before, which does not fix.

[ian-axelrod]

Oh.... I didn't know that. Testing that out now.

[ian-axelrod]

Yep. That works. Thanks!

[joshmanderson]

+1
Thanks @nuzz for the reset tip 👍

[FranklinYu]

Looks like this is fixed by moby/moby#33502.

There is some way to get back the old version, if you upgraded within Docker.app: #1120 (comment)

[egikyan]

Hey guys,

I'm running Version 17.06.0-rc1-ce-mac13 (18169) and both of the workarounds mentioned (reset/stty sane work). You should run it inside the container. So for example if you were running :

docker exec -it container_id /bin/bash "./vendor/bin/phpunit"

you should now run

docker exec -it container_id /bin/bash -c "stty sane && ./vendor/bin/phpunit" (or)
docker exec -it container_id /bin/bash -c "reset && ./vendor/bin/phpunit"

First option is better, as it doesn't clear your input :)

P.S. There is no issue if you don't use the interactive flag. thanks @narqo for mentioning it.

[narqo]

@egikyan you might also drop --interactive (-i) flag if a script you run doesn't require stdin to be attached.

[pgsimon]

+1

The reset command works for me. Thanks @nuzz

[johanneswuerbach]

Created an issue docker/compose#4910

[mmickan]

Just in case this is hitting others too: I was still seeing this while using the docker daemon from 17.06.0-rc2-ce-mac14, until I realised my docker client was an earlier version:

$ docker --version
Docker version 1.12.1, build 23cf638
$ which docker                                                                                                                                                                            /opt/boxen/homebrew/bin/docker
$ brew remove docker
Uninstalling /opt/boxen/homebrew/Cellar/docker/1.12.1... (10 files, 10.8M)
$ docker --version
Docker version 17.06.0-ce-rc2, build 402dd4a

After that, I no longer see the issue.

[FranklinYu]

@mmickan Mixing “brewed Docker” and “Docker for Mac” is never a good idea 😄

If you really miss Homebrew, try brew cask install docker-edge

[rfay]

The reality is that I'm still seeing this problem consistently in Version 17.06.0-rc2-ce-mac14 (18280), at first I hoped it was resolved (and thought I saw it work a time or two), but it's definitely not resolved.

$ docker version
Client:
 Version:      17.06.0-ce-rc2
 API version:  1.30
 Go version:   go1.8.1
 Git commit:   402dd4a
 Built:        Wed Jun  7 10:02:52 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.06.0-ce-rc2
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   402dd4a
 Built:        Wed Jun  7 10:02:04 2017
 OS/Arch:      linux/amd64
 Experimental: true

[hansmaaherra]

@rfay are you running docker-compose?
docker/compose#4910

[rfay]

Yes, starting containers with docker-compose, but using docker to access them. I thought that docker/compose#4910 was about people using docker-compose exec, but I'm using docker exec and related to go into containers started by docker-compose- thanks for the feedback.

[FranklinYu]

@rfay That may be due to a different cause; I suggest to wait for next RC which may or may not fix your issue (possibly because Docker and Docker Compose are tangled with each other somehow).

[mkubenka]

Looks like finally fixed in the latest edge version:

Version 17.06.0-rc4-ce-mac15 (18357)
Channel: edge
ca800595f4

[izaac]

@mkubenka yes this is no longer happening in this new update.

[dlin-me]

Confirmed:
issue exists in Docker version 17.06.0-ce-rc2, build 402dd4a
issue is gone in Docker version 17.06.0-ce-rc5, build b7e4173

[FranklinYu]

I think this can be closed unless there is any further report.

[mfurlend]

not fixed for me in edge version
Version 17.12.0-ce-mac45 (21669)

[rulatir]

No workarounds mentioned work for me. Requesting reopening...

[zhao-lin-li]

@rulatir it is still working for me. Maybe try reinstalling because it does not sound like a widespread issue anymore. Hope that helps :)

[FranklinYu]

This issue did not occur on my machine in 17.12.0-ce-mac49 (21995). @mfurlend @rulatir @kind3r re-install?

[kind3r]

It's wierd, I did not make any changes and there were no updates, but now it's working as it should on 17.12.0-ce-mac49 (21995).

[thehesiod]

broken for me in 18.02.0-ce when pasting text from text-wrangler to vi session

[FranklinYu]

@thehesiod What if you simply hit returns in Bash?

[thehesiod]

@FranklinYu not sure what you mean? my scenario: copy multiline text from text-wrangler, run vi in fresh debian:stretch container, hit i for insert mode, then apple+v to paste, result is the garbled text like shown by @themccallister

[FranklinYu]

@thehesiod How about this scenario: run interactive bash in fresh debian:stretch container, then hit Enter.

[thehesiod]

that works fine, it's just pasting that's the issue

[zhao-lin-li]

@thehesiod what you described might be a thing with VI and copying and pasting. Try :set paste and set nopaste

To isolate whether the issue is VI or docker for Mac, try using just the shell and not VI.

Good luck :)

[thehesiod]

@zhao-lin-li perhaps, actually I just noticed that if I run vi and then insert an paste it works fine, if I run vi /tmp/foo.txt to specify the filename upfront and then paste it doesn't, so ya perhaps not a docker issue.

[andradei]

@thehesiod Maybe your vi distribution is preconfigured this way. I have the same behavior on my local and Docker vims and do what @zhao-lin-li say in order to get thins pasted right.

[thehesiod]

@andradei I'm using debian:stretch so a straight image. This behavior does not occur on my native mac.

[andradei]

@thehesiod It does behave like that on my mac, though. Regardless, this is very likely to be a vi thing, rather than a Docker for Mac thing. So put set paste on your .vimrc of do as @zhao-lin-li suggested and you'll be good to go. Pasting wasn't always smooth on vi.

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked