Terminal prompt got strangely replicated when resizing terminal horizontally

[Norbert]

Steps to reproduce:
1. Have Ubuntu installed
2. Launch MATE Terminal
3. Navigate to some folder with long name - `cd /usr/share/doc/ayatana-indicator-application`
4. Resize terminal horizontally

Expected results:
* terminal shows the same "user@host:/usr/share/doc/ayatana-indicator-application$" with single occurrence

Actual results:
* terminal shows multiple occurrencies of "user@host:/usr/share/doc/ayatana-indicator-application$"

(see attached screencast)

ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: mate-terminal 1.24.1-1
ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12
Uname: Linux 5.11.0-16-generic x86_64
ApportVersion: 2.20.11-0ubuntu65
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: MATE
Date: Tue May 4 10:54:59 2021
InstallationDate: Installed on 2021-04-23 (10 days ago)
InstallationMedia: Ubuntu-MATE 21.04 "Hirsute Hippo" - Release amd64 (20210420)
SourcePackage: mate-terminal
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Norbert (nrbrtx)]

Previous Ubuntu versions like 18.04 LTS, 18.10 do not have such an issue.

The bug was first introduced in Ubuntu 19.04.

[R_volkmann (r-volkmann)]

Can confirm this, it also affects Tilix and Gnome-Terminal (Ubuntu 20.04, Gnome 3.36.4).

[Brian Warner (batycoon)]

Disagree with 18.04 LTS (18.04.5) comment by @nrbrtx, considering gnome-terminal.

Open gnome-terminal.
Change directory to long name, from first character of username to last character "$" of directory summing 60, or 61+ characters.
Give it best effort and utilize "clear" command.
Utilize keyboard shortcut to escape from current command, "CTRL + C", twice.
Utilize keyboard shortcut to adjust window, "ALT + F8", and reduce horizontal width from the RIGHT edge to 62 characters. Notice one line of history is gone.
Continue and reduce horizontal width to 58 characters. Notice an unexpected character at beginning of last line of prompt.
Continue to 57 characters. The whole path is no longer visible.
Continue to 56 characters. Part of the path appears inside the cursor.
Continue to 55 characters. Path is now obscured.
Continue to 50 characters. Notice the obscured path is no longer present, but the path is not whole.
Continue and reduce horizontal width to minimum (31) from the RIGHT edge with arrow keys.
Utilize keyboard shortcut to escape from current command, "CTRL + C", twice.
The tool to change horizontal width has been disabled and a ^C is made visible at the last prompt, escaping to a new prompt with full path.
Utilize keyboard shortcut to adjust window, "ALT + F8", and increase horizontal width from the RIGHT edge to 60 characters or 61 characters. Notice the username is obscured.

If performed with 60 character line, Continue to typical 80 characters. The first letter of the username is now repeated on the last line.

If performed with 61 character line, first character of username is sometimes repeated on previous line.

If performed with 61+ character line, multiples of path are seen as original bug reports. You can make more lines with path appear if iterating between width of 31 and 32 characters.

My example is 62 characters:
userna@userna:~/userna/usernamefolder/direct/foobars/foobars$

Results:
userna@userna:~/userna/usernamefolder
userna@userna:~/userna/usernamefolder/direct/foobars/foobars$

Either with fast keyboard strokes or slow, there are a number of errors in line feed and character removal when adjusting the terminal width.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Fernando Vitor Ventilari Neder (theneverchosen)]

I can confirm this. I'm using Ubuntu 20.04.2 LTS and GNOME Terminal has the same issue.

[William Andrea (wjandrea)]

I can reproduce the same issue with Python and Node interpreters but not Dash. I think the problem is related to readline, because the issue only affects the line where the cursor is, and if I launch Python without it (gnome-terminal -- python3 -I), I can't reproduce the issue.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Egmont Koblinger (egmont-gmail)]

(Former VTE developer here)

A terminal emulator's job is to execute the precise instructions it receives from the connected application (e.g. bash), and in this case, VTE does that correctly. It's bash (or some other readline app) that asks the terminal to print the prompt over and over again, and VTE does so.

There's one thing that VTE does differently than some other terminal emulators, though. Upon resizing the width, it rewraps the contents.

I'd argue that this "rewrap on resize" is the single best improvement VTE received during the last decade, it improves the experience of using the terminal so much... well, improves the experience except for the shell prompt.

What happens is: The terminal rewraps the existing lines on a resize, and then the shell (which is notified by the resize) assumes that the terminal did not rewrap the lines and it reprints the prompt according to this assumption. Unfortunately this assumption is false, the cursor is not where bash believes it to be, and thus reprinting the prompt goes wrong.

(Note: This feature was released in VTE in spring 2014. Since then, there was one particular bash version (4.3 or 4.4, can't recall) that didn't reprint its prompt when the window got resized, therefore the bug didn't occur there.)

What could be done to fix this situation?

In GNOME Terminal you can disable rewrapping on resize. In dconf-editor navigate to /org/gnome/terminal/legacy/profiles: followed by the Profile ID, there you'll find the config option. While it fixes the prompt's behavior, you'll notice that it also modifies the behavior on earlier lines to a less fortunate one.

In case anyone would suggest that VTE should do some "magic": try to figure out if the last line is a shell prompt, and rewrap everything except that last line: No, any approach like this would lead to an utter chaos that is fragile, somewhat working (but there'd always be cases that are still handled incorrectly), different in every terminal, unmaintainable... No, not going to happen.

So, what would be the real solution?

The only real solution is for bash/readline to introduce the possibility (config option) to assume that the terminal has already rewrapped the lines, thus it doesn't need to reprint the prompt (or if it wishes to reprint then takes into account the rewrapping that has already happened).

VTE is not the only terminal out there rewrapping the lines on resize. It wasn't the first one to do this, and wasn't the last one to add this feature either. More and more terminals can do this, and for every newly appearing terminal emulator engine this behavior is pretty much the expectation nowadays.

bash needs to catch up with this widespread change that happened in the terminal world.