Line wrapping problem in bash on ubuntu on windows

[jiangfengming]

When the line is full, terminal doesn't start a new line, instead of starting at the same line and eating the chars.

• VSCode Version: 1.8.1
• OS Version: Windows 10 Pro Insider Preview Version 1607 Build 14986.1000

Steps to Reproduce:

1. Config "terminal.integrated.shell.windows": "C:\\Windows\\sysnative\\bash.exe"
2. Open integrated terminal
3. Input something long to make the line wrap

[jiangfengming]

The problem is not occur every time, try killing the terminal and reopen might occur.

[CherryDT]

It appears to me that this only happens when maximizing the window. The point where it Incorrectly wraps is the previous width of the terminal while the window was not maximized.

[Tyriar]

Much work has happened in the next build, could you try this out again on the Insiders build?

[CherryDT]

@Tyriar I'm on 1.9.0-insider and I can confirm that it still happens there.

[john-osullivan]

Not sure if this is directly related to VSCode, I found this Issue while trying to figure out why the Bash on Ubuntu on Windows was failing to properly wrap lines. Don't believe I had this issue three weeks ago, cropped up for me in a recent Windows update. I'm on Version 1607, OS Build 15017.1000, and am running into this bug.

[adeeb1]

I am still experiencing this issue, and it is very annoying. I'm running VSCode 1.9.1 on Build 14986.rs_prerelease.161202-1928. Bash on Windows does not have the line wrapping issue. Please consider prioritizing this, as it reduces the terminal's usefulness significantly.

[CherryDT]

I'm now on 1.12.0-insider and Windows build 15063.13 and the issue is still there and still very annoying. This issue is labeled as "needs more info" - what info is needed? How can I provide it to help resolving the problem?

[Tyriar]

@CherryDT you're likely seeing #19665 which is being looked at by another team.

[CherryDT]

@Tyriar I'm not so sure, because actually #19665 sounds like the same as #25133 and #25126 (causing text to shift to the left and the cursor to stay), and this problem instead causes lines to wrap before they reached the end and then overwrite the text on the same line from the left (not shifting anything and not separating the text from the cursor).

Also it would appear that #19665/#25133/#25126 are triggered by specific characters or other similar things which happen inside the console, while this issue is triggered by maximizing VSCode (regardless of what happens in the console).

Apart from that, I have this issue for months now, while the other issue (with shifted text) started only a few days ago for me.

[Tyriar]

@CherryDT ah ok, I was wondering if this one was still happening. I assumed you were seeing the other one due to the flood of reports I was going through after Creator Update started going out.

[CherryDT]

@Tyriar OK so the question remains what "more info" is needed for you to get to the bottom of this? I will be glad to help where I can...

[CherryDT]

@Tyriar A little update, I investigated a bit more. It is not only limited to maximizing. The issue happens as soon as the window width is increased rapidly.

When I use the window border to resize it, it gets a WM_SIZE on every few pixels and this appears to work fine. However when I maximize the window or when I use the MoveWindow API to increase the window size by 50 pixels at once or so, it doesn't work and this problem starts appearing.

It will then start incorrectly wrapping and overwriting itself at that specific position where the wrapping point was before the sudden width change.

[Tyriar]

@CherryDT so it looks like there's 2 issues here:

• The terminal is not resizing when you maximize, I would think these bugs are all squashed at this point but to check this you can try ls to see if the output expands beyond the width you're expecting. You can also inspect the terminal in devtools (Help > Toggle Developer Tools) and screenshot the DOM. I'm interested in the contents of .xterm-rows
• The line isn't being wrapped, this is likely an upstream problem in https://github.com/rprichard/winpty

[CherryDT]

@Tyriar Hm, in fact it behaves very strangely because things like ls do expand correctly, however other things (like nano) do not. What I also found now is that opening vim fixes the problem, and so does nano (but for nano it is fixed only after it is closed again), but it's not 100% fixed because it will then still overwrite itself in some cases even though the width is fixed.

Also I noticed that after the maximizing, it can be possible to add more characters at first but then it starts wrapping and "looping" to a smaller width. All kinda hard to explain.

Here you have an illustration of what is happening: http://recordit.co/npWkMirE0r

[CherryDT]

@Tyriar Sorry forgot the devtools before - here is a screenshot: https://i.imgur.com/LeazsIQ.png

[Tyriar]

@CherryDT thanks for the follow up 😃

@rprichard any idea what's going on in the screencast/screenshot above? It looks like the terminal width is correctly bring set but there's some really weird wrapping behavior happening in WSL. AFAIK there has always been weird prompt wrapping behavior like this.

[CherryDT]

"always been weird prompt wrapping behavior": What do you mean by "always"? Always (in time) when resizing, or always (in cases)?

The prompt wraps just fine if I start with a small width, before changing the size:

[Tyriar]

@CherryDT by always I mean since the integrated terminal was introduced, I noticed oddities like this when I was playing with WSL many months ago.

[rprichard]

I'm able to reproduce this issue. I see problems both with wrapping the bash command-line and with vim. I also notice that the $LINES and $COLUMNS variables in bash aren't always updated. I see that the variables are wrong even with the normal Windows console -- the variable represents the size of the console window (rows x cols), but it isn't updated until the console buffer size changes. If you resize the integrated VSCode terminal vertically, $LINES won't be updated at all, because the console buffer is always fixed at 3000 lines.

Aside: winpty's window-resize code is sadly complicated because Windows doesn't provide an API that Just Works. It provides one API that changes the window size (subject to various constraints), another API to change the buffer size (subject to other constraints), and a final API that (supposedly?) changes both, as well as a bunch of other things that applications want to change (e.g. the current text color), so winpty can't use it.

I'll dig into this more. The fix is probably, "do something that triggers another resize notification".

...

There isn't a console input event for a changed window size, but there is one for a changed buffer size.
WINDOW_BUFFER_SIZE_RECORD.

If nothing else, I bet winpty could synthesize WINDOW_BUFFER_SIZE_RECORD events. The most important thing about that event isn't the buffer size field, but the fact that it arrives after the window size has changed.

[rprichard]

I created a winpty issue, rprichard/winpty#110.

[CherryDT]

Cool, thanks for looking into it! I just wonder why it will then wrap without going to the next line...

[rprichard]

My guess: The line-editing system (e.g. readline) thinks the terminal has advanced to a new line when it really hasn't, and maybe when readline alters a line, it redraws a whole line. To do that, it first returns to the start of the line with CR.

[CherryDT]

Is there any ETA when this fix (which is already closed in winpty) will make it into VSCode?

[rprichard]

I could release the next winpty version if that helps.

[CherryDT]

Cool, I hope it will aid in getting this released in VSCode soon.
By the way, is "needs more info" still applicable here?

[Tyriar]

If a winpty release goes out, provided there are no regressions this should make it into the May release.

[rprichard]

I published winpty 0.4.3, which contains the fix for this issue.

If anyone wants to test it before VSCode updates its winpty, it should be possible by replacing the winpty.dll and winpty-agent.exe files in VSCode (in %ProgramFiles(x86)%\Microsoft VS Code\resources\app\node_modules\node-pty\build\Release) with the corresponding two files from ia32\bin of winpty-0.4.3-msvc2015.zip. (VSCode is always a 32-bit program, even on 64-bit Windows, so you want the ia32\bin directory, not x64\bin.)

FWIW: this winpty release has fixes for three other issues that affected VSCode (arrow keys in the Ruby REPL, AltGR keys, and the 5px console font height).

[Tyriar]

Anyone experiencing the issue could you test in tomorrow's Insiders build? It seemed to work fine on my machine with the update.

[chrmarti]

• VSCode Version: Code - Insiders 1.13.0-insider (f977399, 2017-06-02T10:45:30.209Z)
• OS Version: Darwin x64 15.6.0

Seeing this on Linux and Mac (haven't tried Windows) with the first terminal in a new window.

[Tyriar]

@chrmarti there's another issue tracking that, this one is strictly about Windows.

[CherryDT]

Looks solved to me :)

[roblourens]

@Tyriar I see this in Windows in the first terminal of a new window, the width is not measured correctly but wrapping is ok. If I resize anything, it lays itself out correctly. Expected or new issue?

[Tyriar]

@roblourens I'm aware of it, and it's related to #20505. I don't think there's an issue yet so created #28138

[StevieIsmagic]

Hello, I am running VSC Version 1.18.0 on OSX High Sierra. I am experiencing this same behavior - text overwrites the bash shell command prompt - upon having added an emoji to my command prompt. This happens no matter the window size and also on multiple terminal tabs.