Line wrapping issue typing long commands in bash

[d11wtq]

I have no idea what might be causing this, but I have confirmed that it only happens when running docker via fig.

If I start a bash shell inside a docker container, then start typing a long command at the bash prompt, I get to maybe 50-60 characters across the window, then the line wraps back on itself and I'm then typing over the top of what I've already written. It doesn't affect the input, only the rendering of the shell.

See copy/paste of an example below. The | indicates where the cursor is (this is the end of the line, not the middle of some gibberish).

vagrant@gentoo ~/environments/python2 $ fig run --rm console bash
 wrap around back onto the same line?|really long command here, and it's going to

Using the exact same docker image without fig:

vagrant@gentoo ~/environments/python2 $ docker run --rm -ti d11wtq/python:2.7.7 bash
default@de72b52f7075:~$ I'm typing a really long command here, and it's going to wrap around back onto the same line?|

[d11wtq]

Opening vi in the window, it seems confused as to how big the terminal is too, as it (correctly) wraps at the incorrect column, after 79 characters have been typed. I guess fig is hard-coding the terminal size somehow? Not sure why bash doesn't wrap properly. It would be good to have fig run work just like docker run anyway :)

[aanand]

Yes, see #97. The docker client dynamically resizes the pseudo-TTY, which involves repeated POSTs to the Docker API (see cli.monitorTtySize and cli.resizeTtty). We need to do that too.

[d11wtq]

Ah cool. I might have a look at this. I actually spent all evening yesterday going down a rabbit hole thinking this was likely to be an issue in SocketClient itself.

[d11wtq]

Also out of curiosity, what's the reason for bundling the docker client directly in this repo, rather than referencing it as a dependency in PyPi?

[bfirsh]

We used to depend on some features that were not in a released PyPi version of docker-py. It's quite possible that's not the case any longer.

[d11wtq]

I'm diffing the two codbases (current master vs your embedded one) and it looks mostly like you're missing new features in the upstream version, but aren't implementing things that don't exist.

Have you sent PR's upstream?

Might try to undo this and get back onto the official client, so people can send PRs to them before making changes in fig (e.g. docker/docker-py#246 can go with #263).

[arielpontes]

I still get this all the time running Docker on Mac. I realized that if I simply resize the terminal window after attaching to the container, the problem is fixed.

[Dayjo]

@arielpontes thank you! This has been driving me a little loopy, wasn't really sure where the issue lay.

[majanpaul]

@arielpontes God bless you ...

[girishadurrel]

@arielpontes thanks dude!

[dead10ck]

This seems to be back in 1.19.0. Running Arch Linux.

[bossjones]

@arielpontes seriously, thank you.

[ihnorton]

x-ref: moby/moby#25450

[zinovyev]

@arielpontes thank you so much! =)

[eulerreich]

I'm still getting this glitch as well. Thanks @arielpontes for the tip, but it'd be nice if this is resolved to begin with.

[majuscule]

This problem remains on Docker version 17.12.0-ce, build c97c6d6 on osx.

[jasonsemko]

Happening for me in 18.03.0-ce-mac60 (23751) 6ddfc0f1d3

[zinovyev]

Docker version 18.03.0-ce, build 0520e24302 Archlinux

[belugame]

also for me on Ubuntu 16.04 with i3wm

[k1r8r0wn]

I've blamed oh-my-zsh, pry, pry-rails, readline and in the end here it is - docker-compose... 🤣

Thanks, @arielpontes, kinda solution.

Version 18.03.0-ce-mac60 (23751)

[ghost]

@arielpontes +1! Thank you!

[davecremins]

You've no idea how much this was annoying me, thanks for the resize fix 👍

[patakijv]

Thanks @arielpontes, the quick manual resize of the terminal window appears to help with this annoying problem, as far as I can tell with a few tests just now. Crossing my fingers for it to be the workaround that sticks around.

Is there any way to script or automate the resize of the terminal window so I can drop it into my .bashrc or something like that? I am in and out of these docker container bash shells often enough that it would be great to through a scripted workaround into my image.

Does anyone have a clue what the actual source of this problem could be so it can be investigated and fixed vs a workaround?

I only noticed this problem since upgrading a few things a couple months ago like the Docker For Mac version and MacOS from El Capitan to High Sierra. Prior to a couple months ago and those updates, I never had this issue but now I get it all the time.

[qmcree]

I also have this issue in a container shell reached via docker-compose exec or run using Docker for Mac. When the command should wrap to the next line, it instead overwrites the current line. Additionally, the constrained width is a lot less than the width of my terminal. Resizing the window does fix this temporarily, but what is the core issue?

[teohhanhui]

I was going to blame Visual Studio Code, but turns out it's Docker Compose. Manual resizing also fixes the problem.

[qmcree]

Haha, yes, I have been blaming PyCharm for the longest time, but it is, in fact, caused by Docker Compose.

[meglio]

docker-compose version 1.21.1 - this still happens to me:

hen the command should wrap to the next line, it instead overwrites the current line.

So, is there a workaround?

[qmcree]

@aanand Can you reopen this issue, since it still exists, or was reintroduced?

[sobi3ch]

After attaching, resize the window!

[sophylee]

We're still seeing the same issue as well and the resizing workaround doesn't work :( . Can we reopen?

[Wolvverine]

the same problem

[smeggingsmegger]

@sophylee I've found a few solutions in MacOS if that helps.

One is to set the width once you are inside your bash prompt:

stty columns 270 works really well for my monitor. You'll need to find the right number for yours.

Also, in iTerm2 I edited my profile to set the width of new sessions automatically and now it just works inside my docker container. Open Profiles -> Edit -> Window -> Columns: 270

I hope this helps!

[sophylee]

@smeggingsmegger thanks for the help! I tried both setting stty columns and updating my iTerm2 profile using different width values, in both zsh and bash. (Restarting iTerm2 each time.) No luck unfortunately. The line still wraps at the same location as before.

[thaJeztah]

moby/moby#35407 is now fixed on master through moby/moby#37172

[linboosted]

@arielpontes 好牛啊

[alfuken]

@d11wtq why is this closed? it's still an issue.

[thaJeztah]

This is a 7 year old issue for a bug that was fixed at the time; if you're running into something the looks like this, it's not related to the original issue.

If you have details about your issue, and exact steps to reproduce, please open a new ticket instead.

[mhenrixon]

Seems like docker compose brought back this old friend @thaJeztah :)

[thaJeztah]

😞 definitely not related though, because docker compose (docker <space> compose) uses an entirely different codebase.
I see there's a ticket opened in docker-archive/compose-cli#1640 to track that issue

[daniel-santos]

Eew, how am I getting this in 2024 with Docker 26.0.0? I did install libcurses in my container and I'm a set -o vi guy, so I wonder if that's related. Container is mcr.microsoft.com/dotnet/sdk.

EDIT: AH HAH! Looks like all of the pseudo-tty kinks aren't quite worked out. I only need to set my little pet PS1 prompt to get it. Looks like this needs a new ticket

export PS1='\e]0;\u@\h\a\[\e[49m\]\[\e[01;34m\]${PWD}\n\[\e[39m\](\u@\h)\[\e[01;34m\]\$\e[0;0m '