Обсуждение: psql: Buggy interactions with wraparound in maximized gnome terminals.
This is probably hard to reproduce, but I entered a state where the command I was writing was wrapping around at the 81st character while in full screen, and the 1st character was being overwritten.This did not affect the command sent to the server, but I would not have a way to see what command I just entered. I'm using ubuntu 18.04, the terminal is Gnome Terminal 3.28.2 Below is a short video showcasing the issue. I thought I had muted my mic, but apparently I didn't, please enjoy my nation's anthem while observing said bug. https://drive.google.com/file/d/1Xdj96v2StfM9E7HuM5NOsnOVssjw5fcg/view?usp=drive_web Additionally, while researching this bug, I found a reproducible variation of this bug: 1- Open a terminal at a normal size. 2- Write enough characters so that they correctly wrap around into a new line. 3- Maximize the window 4- Minimize it again You will find that the command is visibly duplicated. Again this is aesthetic, the command is not duplicated when it's sent to the server. You can find a video of this bug below (I gotta learn how to turn that mic off) https://drive.google.com/file/d/1M102uK6yTHyLhEKtR_UsObzwMaaI2teX/view?usp=drive_web Good luck! Let me know if you need any help.
Tomas Zubiri <me@tomaszubiri.com> writes:
> This is probably hard to reproduce, but I entered a state where the
> command I was writing was wrapping around at the 81st character while
> in full screen, and the 1st character was being overwritten.This did
> not affect the command sent to the server, but I would not have a way
> to see what command I just entered.
You probably need to discuss this with the readline folks, not us.
regards, tom lane
Ok, makes sense. Since psql depends on readline, I'm adding their bug mailing list to the loop, and reposting the original bug report: This is probably hard to reproduce, but I entered a state where the command I was writing was wrapping around at the 81st character while in full screen, and the 1st character was being overwritten.This did not affect the command sent to the server, but I would not have a way to see what command I just entered. I'm using ubuntu 18.04, the terminal is Gnome Terminal 3.28.2 Below is a short video showcasing the issue. I thought I had muted my mic, but apparently I didn't, please enjoy my nation's anthem while observing said bug. https://drive.google.com/file/d/1Xdj96v2StfM9E7HuM5NOsnOVssjw5fcg/view?usp=drive_web Additionally, while researching this bug, I found a reproducible variation of this bug: 1- Open a terminal at a normal size. 2- Write enough characters so that they correctly wrap around into a new line. 3- Maximize the window 4- Minimize it again You will find that the command is visibly duplicated. Again this is aesthetic, the command is not duplicated when it's sent to the server. You can find a video of this bug below (I gotta learn how to turn that mic off) https://drive.google.com/file/d/1M102uK6yTHyLhEKtR_UsObzwMaaI2teX/view?usp=drive_web Good luck! Let me know if you need any help. El vie., 20 de dic. de 2019 a la(s) 18:21, Tom Lane (tgl@sss.pgh.pa.us) escribió: > > Tomas Zubiri <me@tomaszubiri.com> writes: > > This is probably hard to reproduce, but I entered a state where the > > command I was writing was wrapping around at the 81st character while > > in full screen, and the 1st character was being overwritten.This did > > not affect the command sent to the server, but I would not have a way > > to see what command I just entered. > > You probably need to discuss this with the readline folks, not us. > > regards, tom lane
On 12/20/19 4:48 PM, Tomas Zubiri wrote: > Ok, makes sense. Since psql depends on readline, I'm adding their bug > mailing list to the loop, and reposting the original bug report: > > This is probably hard to reproduce, but I entered a state where the > command I was writing was wrapping around at the 81st character while > in full screen, and the 1st character was being overwritten.This did > not affect the command sent to the server, but I would not have a way > to see what command I just entered. It seems like the readline SIGWINCH handler, which causes it to update its idea of the screen dimensions, isn't being called. I can't reproduce this using readline and bash, and I don't know what postgres does with its signal handling, or how it configures readline's signal handling (I assume it doesn't do anything special). I'll look at little more at something that doesn't modify the readline signal handling defaults and see if I can reproduce it. > > I'm using ubuntu 18.04, the terminal is Gnome Terminal 3.28.2 > > Below is a short video showcasing the issue. I thought I had muted my > mic, but apparently I didn't, please enjoy my nation's anthem while > observing said bug. I did enjoy it. :-) > > https://drive.google.com/file/d/1Xdj96v2StfM9E7HuM5NOsnOVssjw5fcg/view?usp=drive_web > > Additionally, while researching this bug, I found a reproducible > variation of this bug: > > 1- Open a terminal at a normal size. > 2- Write enough characters so that they correctly wrap around into a new line. > 3- Maximize the window > 4- Minimize it again > > You will find that the command is visibly duplicated. Again this is > aesthetic, the command is not duplicated when it's sent to the server. This one's easy to explain. By the time readline's SIGWINCH handler is called, the terminal has already wrapped and redisplayed the text, leaving the cursor at the end of the text on the second line. Readline has no way of knowing this, and performs a full redisplay. This involves moving to column 0 of what it thinks is the first screen line of the current line being entered (it thinks that is line 0, since it doesn't know what the terminal has done and, as far as it knows, the line isn't wrapped), clearing the line, and performing a full redisplay including reprinting the prompt. That obviously leaves the other lines, the ones the terminal wrapped before sending SIGWINCH, visible on the screen. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
Chet Ramey <chet.ramey@case.edu> writes:
> On 12/20/19 4:48 PM, Tomas Zubiri wrote:
>> This is probably hard to reproduce, but I entered a state where the
>> command I was writing was wrapping around at the 81st character while
>> in full screen, and the 1st character was being overwritten.This did
>> not affect the command sent to the server, but I would not have a way
>> to see what command I just entered.
> It seems like the readline SIGWINCH handler, which causes it to update its
> idea of the screen dimensions, isn't being called. I can't reproduce this
> using readline and bash, and I don't know what postgres does with its
> signal handling, or how it configures readline's signal handling (I assume
> it doesn't do anything special).
We don't touch SIGWINCH at all, so if readline sets up a handler for that,
it ought to behave as expected.
I notice though that we do this just before each readline() call:
/*
* Some versions of readline don't notice SIGWINCH signals that arrive
* when not actively reading input. The simplest fix is to always
* re-read the terminal size. This leaves a window for SIGWINCH to be
* missed between here and where readline() enables libreadline's
* signal handler, but that's probably short enough to be ignored.
*/
#ifdef HAVE_RL_RESET_SCREEN_SIZE
rl_reset_screen_size();
#endif
Is it conceivable that that bollixes things somehow, on some builds?
(I don't think the OP specified which readline and/or Postgres version
he was using.)
regards, tom lane
>(I don't think the OP specified which readline and/or Postgres version he was using.) That would be postgres 12.1 and readline 7 Tomas Zubiri Software Developer Cel: +54 911 5891 8239 El sáb., 21 de dic. de 2019 a la(s) 18:41, Tom Lane (tgl@sss.pgh.pa.us) escribió: > > Chet Ramey <chet.ramey@case.edu> writes: > > On 12/20/19 4:48 PM, Tomas Zubiri wrote: > >> This is probably hard to reproduce, but I entered a state where the > >> command I was writing was wrapping around at the 81st character while > >> in full screen, and the 1st character was being overwritten.This did > >> not affect the command sent to the server, but I would not have a way > >> to see what command I just entered. > > > It seems like the readline SIGWINCH handler, which causes it to update its > > idea of the screen dimensions, isn't being called. I can't reproduce this > > using readline and bash, and I don't know what postgres does with its > > signal handling, or how it configures readline's signal handling (I assume > > it doesn't do anything special). > > We don't touch SIGWINCH at all, so if readline sets up a handler for that, > it ought to behave as expected. > > I notice though that we do this just before each readline() call: > > /* > * Some versions of readline don't notice SIGWINCH signals that arrive > * when not actively reading input. The simplest fix is to always > * re-read the terminal size. This leaves a window for SIGWINCH to be > * missed between here and where readline() enables libreadline's > * signal handler, but that's probably short enough to be ignored. > */ > #ifdef HAVE_RL_RESET_SCREEN_SIZE > rl_reset_screen_size(); > #endif > > Is it conceivable that that bollixes things somehow, on some builds? > (I don't think the OP specified which readline and/or Postgres version > he was using.) > > regards, tom lane