GNOME Bugzilla – Bug 780995
gnome-terminal's buffer (lines) are corrupted when the window is resized (zsh)
Last modified: 2021-06-10 15:20:30 UTC
Created attachment 349415 [details] A gif showing the issue. Hey, I am having this issue since I have been using gnome so I am not sure if this worked before. Also I am not sure if this a issue with gnome-terminal/vte/zsh but some google results pointed me to vte so here I am. To get to the actual issue, this behavior can be reproduced by simply by resizing the gnome-terminal window with zsh as shell (This can be reproduced with Archlinux and Ubuntu 16.10 and perhaps other distros as well.) I have also embedded a gif which shows this issue further.
It seems that this isn't zsh's fault because it could reproduce this behavior with bash. I've attached another gif showing this issue with bash.
Created attachment 349417 [details] Bash
Please see bug 778547.
Yes, Thank you, but it seems to me that my issue also affects bash as you can see in the gif. Also I tried to disable wrapping in gnome-terminal and set PS1 to '\e[?7l[\u@\h \W]$ \e[?7h' just like you said. Unfortunately I am getting a different behavior which removes everything I had in the buffer above the current prompt. I've attached another gif showing this.
Created attachment 349486 [details] bash with the patch and wrapping disabled
For bash, you need to enclose nonprintable characters of the prompt between \[ and \], e.g. PS1='\[\e[?7l\][\u@\h \W]$ \[\e[?7h\]' What's your bash version? bash-4.3 delays delivering SIGWINCH until the next keypress or similar event. Bash up to 4.2 didn't suffer from this issue, and apparently 4.4 is fixed again (at least in Zesty, maybe Ubuntu patched it, I haven't checked). Also let me point you to bug 780011 that was just fixed recently which is another issue with bash line editing (but not the one you're having).
I am on ArchLinux so it's Version 4.4.12(1)-release. Unfortunately with the new PS1 it's still doesn't work. I've attached another gif showing this. (With rewrapping on resize disabled.)
Created attachment 349489 [details] another bash test
I'm pretty certain it's a bash/readline bug. Could you please try the behavior in xterm?
Created attachment 349507 [details] xterm
I've attached a gif which shows the behavior with xterm. So I assume it's a non-vte issue?
Yup.
Hey again, I've emailed a bug-report to the bash developers and it seems that they might have figured out the issue here. I will just quote one of Chet Ramey's response from the thread: > I suspect this happens due to mismatched expectations. The cases with > garbled output seem to occur where the redisplay engine assumes the > terminal maintains the text across resizes (so it can do intelligent > redisplay using what's already on the screen) and the terminal emulator > assumes the foreground process is going to take care of doing all the > redisplay after a SIGWINCH and doesn't bother with the screen contents. > > The readline redisplay engine assumes that the only characters on the > screen are those it writes. If that assumption is violated on a size > change, you'll get indeterminate results. Please see this thread for the full discussion. https://lists.gnu.org/archive/html/bug-bash/2017-06/msg00123.html It seems that gnome-terminal violate this particular assumption which results into the garbage output when the window size is being resized. Is it possible somehow to support this assumption? It seems that this affects multiple shells not just bash (zsh, bash, mksh). Maybe through a flag or something like that? I am not sure if such change will result in compatibility breakage but it seems that most shells rely on this assumption.
Yes, indeed, rewrapping the contents on resize breaks this assumption. Given that in a(n obviously non-representative) poll about 1.5 years ago at https://opensource.com/life/15/11/top-open-source-terminal-emulators, terminal emulators that now (not at the time of the poll) rewrap on resize got around 50-60% of the votes, maybe it's time for readline/bash to reconsider their assumptions. You can easily disable rewrapping in the profile preferences. You will, however, lose one of the coolest features that received by far the most positive feedback in recent years of vte/gnome-terminal. The one that made me join the project. The one that resulted in the biggest productivity boost for me and probably for many other folks. The one that I'm still the proudest of till this day :-) Your call. Could VTE rewrap the entire scrollback, just not the last prompt? Well, that would certainly require tons of future development and cooperation with bash and other shells, because then we would need to know where the prompt is, which we currently don't know and don't care about. It might become handy or even necessary for command completion notification anyway (a stalled feature request), depending on what approach we take there, but there we saw an utter lack of interest from bash devs in cooperating and addressing that request. As such, I have doubts that they'd be open for a cooperation here. Also I personally wouldn't care about such cooperation if it aimed to address this prompt-resize issue only and not the notification one. I'd personally be happy to cooperate with them (time permitting) if we aim to address both this issue and the notification story. Until then, you have a couple of choices. You can disable rewrap on resize. You can disable and then restore wraparound in your prompt, as shown above. Or you can live with this issue. I really don't think it's a serious issue. You need to stress-resize the window for this to occur, which you probably won't do normally. And even if you hit the bug, the consequences are not severe at all. Just a bit of display corruption; you can press ^L to clear/repair the screen, or ^C to cancel the command and start over, or anything alike. It's sure a bit annoying, but IMO nothing big deal. In the mean time I'm wondering... does the workaround of disabling wraparound while the prompt is printed (that is, PS1='\[\e[?7l\].....\[\e[?7h\]') have any drawbacks at all?
Don't get me wrong but I prefer and use the text rewrapping. I am resizing my windows all the time so it's very important for me to have this enabled. Also I've already tried to disable the text rewrapping on resize feature but it still results into this bug where lines are removed/repeated/... (Tested with bash and zsh.) This prompt (with/-out rewrapping on resize): PS1='\[\e[?7l\]username@hostname $\[\e[?7h\]' Also triggers this bug (lines are removed/repeated/...). Well, it's not like that this bug is preventing me from work or anything like that but sometimes (very often actually) it is just annoying to loose terminal content which sometimes contain important stuff I wouldn't want to loose yet :) But yeah, I would really like to see this fixed eventually. Do you mind if I link this bug-report to the bash thread?
(In reply to Peet from comment #15) > Also I've already tried to disable the text rewrapping on resize feature but > it still results into this bug where lines are removed/repeated/... (Tested > with bash and zsh.) Well, that is either a bash/zsh bug then (since VTE does leave the contents unchanged, according to their assumption), or the almost(*) inevitable race condition mentioned at bug 778547 comment 5. > This prompt (with/-out rewrapping on resize): > PS1='\[\e[?7l\]username@hostname $\[\e[?7h\]' > > Also triggers this bug (lines are removed/repeated/...). Oops. Okay. Good to know then. Maybe bash does some optimization of the output (e.g. overwrites a part of the prompt only and throws out these bits then). The exact details are probably not relevant, we just have to sadly accept that this workaround idea does not work. > Do you mind if I link this bug-report to the bash thread? Feel free to (it's an open bugzilla so they could find it anyways). (*) I still think the proper solution (which also protects against the aforementioned almost inevitable race condition) is to temporarily disable wraparound. Apparently you can't do it in $PS1, but readline's prompt displaying engine could do it hardcoded.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2389.