Buffer corruption when the terminal is resized.
I would like to report a bug with bash (readline?). This bug can be reproduced by opening gnome-terminal with bash running. By quickly horizontally resizing the terminal window you can see that the buffer seems to be corrupted as you see repeated or even removed lines or characters. At first I thought this might be an issue with gnome-terminal/vte but this also happens with xterm so the conclusion was that it might be bash/readline's fault. This can be reproduced on stock Ubuntu 17.04. Bash version: 4.4.7(1)-release (x86_64-pc-linux-gnu) System: Linux 4.10.0-22-generic #24-Ubuntu SMP Mon May 22 17:43:20 UTC 2017 x86_64 x86_64 I've also uploaded a gif which shows this behavior: https://media.giphy.com/media/3ohze1ynhK8ZDGmpq0/giphy.gif
Re: Buffer corruption when the terminal is resized.
declare -- PS1="\\[\\e]0;\\u@\\h:
\\w\\a\\]\${debian_chroot:+(\$debian_chroot)}\\[\\033[01;32m\\]\\u@\\h\\[\\033[00m\\]:\\[\\033[01;34m\\]\\w\\[\\033[00m\\]\\\$
"
On Sat, Jun 10, 2017 at 6:47 PM, George wrote:
> On Sat, 2017-06-10 at 11:20 -0500, Eduardo Bustamante wrote:
>
> On Sat, Jun 10, 2017 at 04:56:35PM +0200, Paul Peet wrote:
>
> I would like to report a bug with bash (readline?). This bug can be
> reproduced by opening gnome-terminal with bash running. By quickly
> horizontally resizing the terminal window you can see that the buffer
> seems to be corrupted as you see repeated or even removed lines or
> characters.
>
>
> What's the value of your PS1? (use: declare -p PS1)
>
> It's actually shown in his video link... Looks like at the start of PS1 he
> has \[ and \] surrounding escape characters rather than the whole escape
> sequence:
>
> \[\e\]0;
>
> Rather than:
>
> \[\e0;\]
>
> Bash relies on \[ and \] to determine how much space is occupied by the
> prompt when it is to be redrawn, so in this case it thinks the prompt is 2
> columns wider than it actually is.
Re: Buffer corruption when the terminal is resized.
If I understand this correctly this prompt (see below) shouldn't
contain any invisible sequence, therefore it doesn't require the
wrapping with \[ and \].
PS1="\u@\h\$"
So bash should be able to correctly calculate the prompt size and
such, but by resizing the window it still results in a corrupted
buffer.
I've uploaded another gif which shows this:
https://media.giphy.com/media/xUA7biW8UtwYIU6ggg/giphy.gif
On Sat, Jun 10, 2017 at 6:58 PM, Eduardo Bustamante wrote:
> On Sat, Jun 10, 2017 at 06:49:13PM +0200, Paul Peet wrote:
>> declare -- PS1="\\[\\e]0;\\u@\\h:
>> \\w\\a\\]\${debian_chroot:+(\$debian_chroot)}\\[\\033[01;32m\\]\\u@\\h\\[\\033[00m\\]:\\[\\033[01;34m\\]\\w\\[\\033[00m\\]\\\$
>> "
> [...]
>> > Bash relies on \[ and \] to determine how much space is occupied by the
>> > prompt when it is to be redrawn, so in this case it thinks the prompt is 2
>> > columns wider than it actually is.
>
> George already said it. There are two types of characters inside the
> prompt string, visible and invisible. Color sequences are of the
> invisible kind (these have an effect on the terminal, but do not occupy
> any space on the line). You must wrap invisible character sequences with
> \[ and \], otherwise Readline's calculation to figure out the physical
> lenght of your prompt string will be off, and will cause the effect that
> you're experiencing.
>
> Try with:
>
> # v- this is an invisible sequence.
> PS1='\[\e]0;\]\u@\h:\w\a\$...'
> # ^ ^
>
> instead.
>
> --
> Eduardo Bustamante
> https://dualbus.me/
Re: Buffer corruption when the terminal is resized.
Okay, I did the follwing: > git clone https://git.savannah.gnu.org/git/bash.git > cd bash && git checkout devel > ./configure --prefix=/ --with-curses --enable-readline > make I then changed the default shell (in gnome-terminal) to the newly built bash. > echo $BASH_VERSION 4.4.12(1)-maint Unfortunately, I am still getting the same behavior as before (This also happens with xterm for some reason.) On Sat, Jun 10, 2017 at 11:20 PM, Eduardo Bustamante wrote: > On Sat, Jun 10, 2017 at 07:21:36PM +0200, Paul Peet wrote: >> If I understand this correctly this prompt (see below) shouldn't >> contain any invisible sequence, therefore it doesn't require the >> wrapping with \[ and \]. >> >> PS1="\u@\h\$" >> >> So bash should be able to correctly calculate the prompt size and >> such, but by resizing the window it still results in a corrupted >> buffer. >> >> I've uploaded another gif which shows this: >> https://media.giphy.com/media/xUA7biW8UtwYIU6ggg/giphy.gif > > I can't reproduce this with: > > > dualbus@debian:~/src/gnu/bash$ bash --version | head -n1 > GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu) > > dualbus@debian:~/src/gnu/bash$ xterm -version > XTerm(327) > > dualbus@debian:~/src/gnu/bash$ lsb_release -d > Description:Debian GNU/Linux 9.0 (stretch) > > > Can you reproduce the problem using a more recent version. Perphaps try > the `devel' branch from git? <https://savannah.gnu.org/git/?group=bash> > > -- > Eduardo Bustamante > https://dualbus.me/
Re: Buffer corruption when the terminal is resized.
Uhmm, I am not sure how to interpret these results (All shells or terminals have been tested with Ubuntu 17.04): gnome-terminal + bash: Happens gnome-terminal + zsh: This bug also happens here, lines are getting removed/repeated... gnome-terminal + dash: Does not happen. (I changed the PS1="username@hostname $" to make it longer) gnome-terminal + mksh: The bug also occured here. Same as bash and zsh. konsole + bash: Doesn't happen here. I guess this is because konsole doesn't do text wrapping (The prompt wraps though but not the output alone.) On Mon, Jun 12, 2017 at 6:35 AM, Eduardo Bustamante wrote: > On Sun, Jun 11, 2017 at 12:29:33AM +0200, Paul Peet wrote: > [...] >> Unfortunately, I am still getting the same behavior as before (This >> also happens with xterm for some reason.) > > Please do consider that Readline has little knowledge about what has > been written to the terminal. That's the terminal's reponsability. > > What Readline does is to write your prompt, and place the cursor right > beside the prompt. In both of your animations, the prompt seems to be > rendered fine, I can't really tell because the animation is a bit fast. > > Does the same problem happen if you use a different shell? (zsh, mksh, > dash, ksh93). > > -- > Eduardo Bustamante > https://dualbus.me/
Re: Buffer corruption when the terminal is resized.
I guess this is why I don't get the garbage output with gnome-terminal and dash. Dash doesn't use readline apparently. So, what can be done to actually fix this? On Mon, Jun 12, 2017 at 7:55 PM, Chet Ramey wrote: > On 6/12/17 1:38 PM, Paul Peet wrote: >> Uhmm, I am not sure how to interpret these results (All shells or >> terminals have been tested with Ubuntu 17.04): >> >> gnome-terminal + bash: Happens >> gnome-terminal + zsh: This bug also happens here, lines are getting >> removed/repeated... >> gnome-terminal + dash: Does not happen. (I changed the >> PS1="username@hostname $" to make it longer) >> gnome-terminal + mksh: The bug also occured here. Same as bash and zsh. > > 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. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Buffer corruption when the terminal is resized.
Well, I can try to re-open this issue on the gnome-terminal/vte3 side. Perhaps I can convince them to take an approach where the terminal isn't violating the assumptions of the display engine by introducing a new flag or something like that. On Mon, Jun 12, 2017 at 9:27 PM, Chet Ramey wrote: > On 6/12/17 2:24 PM, Paul Peet wrote: >> I guess this is why I don't get the garbage output with gnome-terminal >> and dash. Dash doesn't use readline apparently. > > Dash doesn't support line editing at all out of the box, though you can > build it using libedit. > >> >> So, what can be done to actually fix this? > > Not a lot, really. If the display engine assumes that the only characters > on the screen are the ones it writes there, and the terminal emulator > violates that on a screen size change, you're basically left with running > ^L (with or without a numeric argument to restrict it to the current line) > a lot. > > Now, if you force a complete refresh with ^L and the display is still > wrong, we have a redisplay bug. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Buffer corruption when the terminal is resized.
Is there a flag in macOS's Terminal? It's because I am also experiencing this bug on macOS's Terminal :) (with bash). On Mon, Jun 12, 2017 at 9:47 PM, Chet Ramey wrote: > On 6/12/17 3:45 PM, Paul Peet wrote: >> Well, I can try to re-open this issue on the gnome-terminal/vte3 side. >> Perhaps I can convince them to take an approach where the terminal >> isn't violating the assumptions of the display engine by introducing a >> new flag or something like that. > > Maybe. I know Mac OS X Terminal manages to do it. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Buffer corruption when the terminal is resized.
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? > [reply] [−] Comment 15 On Mon, Jun 12, 2017 at 10:45 PM, Chet Ramey wrote: > On 6/12/17 4:24 PM, Chet Ramey wrote: >> On 6/12/17 4:08 PM, Paul Peet wrote: >>> Is there a flag in macOS's Terminal? It's because I am also >>> experiencing this bug on macOS's Terminal :) (with bash). >> >> I doubt it. My testing wasn't very scientific. I just opened up a new >> Terminal, ran bash-4.4, typed a bunch of characters, and constantly resized >> the terminal while watching the display. xterm didn't do too badly at >> this, either. >> >> The thing that Terminal does that other terminal emulators (e.g., xterm) >> don't seem to do is rewrap all the text on the screen as the screen gets >> resized. For instance, if I make an xterm very narrow, so that the text on >> previous lines gets `squeezed' and not displayed, that text isn't restored >> when I widen it again. xterm also leaves text on the screen below the >> current line if the screen is narrowed so the current line wraps and >> consumes all of the vertical area, then widened again. This argues for the >> conjecture that other terminal emulators expect the foreground process to >> manage the entire display, not just the current line. > > Now, one thing I didn't mention is that this auto-wrapping of all text can > cause its own problems. Consider the case where the cursor is at the right > side of the screen, and you narrow the screen one or two columns -- just > enough to cause the text to require, say, three lines instead of two. In > this instance, Terminal wraps the text on its own -- meaning the cursor is > now on the third `physical' line -- before sending bash a SIGWINCH. At this > point, readline tries to perform redisplay assuming the cursor is still on > the second line and that the terminal emulator hasn't done anything, so its > position calculations are off from the start. This can easily leave stray > lines of text on the screen that readline doesn't (and can't) know about. > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
