Buffer corruption when the terminal is resized.

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Buffer corruption when the terminal is resized.

Paul Peet
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Eduardo A. Bustamante López
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)

--
Eduardo Bustamante
https://dualbus.me/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

tetsujin
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Paul Peet
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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Eduardo A. Bustamante López
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:

        #  vvvvv- this is an invisible sequence.
    PS1='\[\e]0;\]\u@\h:\w\a\$...'
        # ^      ^

instead.

--
Eduardo Bustamante
https://dualbus.me/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Paul Peet
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 <[hidden email]> 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:
>
>         #  vvvvv- this is an invisible sequence.
>     PS1='\[\e]0;\]\u@\h:\w\a\$...'
>         # ^      ^
>
> instead.
>
> --
> Eduardo Bustamante
> https://dualbus.me/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Eduardo A. Bustamante López
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/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Paul Peet
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 <[hidden email]> 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/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Eduardo A. Bustamante López
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/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Paul Peet
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 <[hidden email]> 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/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Chet Ramey
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, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Paul Peet
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 <[hidden email]> 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, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Chet Ramey
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, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Paul Peet
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 <[hidden email]> 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, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Chet Ramey
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, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Paul Peet
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 <[hidden email]> 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, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Chet Ramey
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.

There's probably some work that can be done with streams of SIGWINCH,
though.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Chet Ramey
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, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Paul Peet
Well, I seriously have no idea what approach would be the right one to
fix this but I've responded on the other side and this was Egmont
Koblinger (vte developer) response:

----
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?
----
https://bugzilla.gnome.org/show_bug.cgi?id=780995


> 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?
> [reply] [−] Comment 15

On Mon, Jun 12, 2017 at 10:45 PM, Chet Ramey <[hidden email]> 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, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buffer corruption when the terminal is resized.

Chet Ramey
On 6/12/17 9:49 PM, Paul Peet wrote:

> 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.

The problem with reconsidering this assumption is that it leaves you with
no recourse but to move to a new line (and who knows, it may be a line
containing newly-wrapped text) and just do a fresh redraw when you get a
SIGWINCH.  That's going to leave even more text on the screen than now, for
gains only in pathological cases.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Loading...