Detectng missed SIGWINCH in Bash extension, when apparent terminal size has not changed

Question

I maintain an extension for the Bash environment called Basta. Basta provides a scroll-protected status line at the bottom of your ANSI/VT100 terminal.

When Basta sets itself up, the effective number of lines, as known by the termios stuff in the kernel and the shell LINES variable decreases by 1. Resizing the terminal is handled nicely. Almost. There is trap for the SIGWINCH signal to call the update routine, which is also called after every command, prior to returning to the prompt.

However, from time to time I see a situation in which the scrolling region is lost. The prompt is being painted over the bottom line, where the user is editing commands and where command output appears, resulting in a mess.

I have a hypothesis on one how it can occur, which has reliable repro steps.

1. We run a program that waits for input, while Bash is in the background, such as cat.

2. While this program is running, we resize the window such that we shrink it by one line.

3. Terminate the cat program.

If the terminal is resized while cat is running, Bash does not get the SIGWINCH (because, I think, SIGWINCH is only sent to the processes in the terminal sessions foreground process group, and Bash is in the Background at that moment). Our trap does not execute.

Basta's update function also relies on comparing the previous terminal size to the current to detect a size change.

Here is the problem: in this situation where a terminal with a scroll-protected status like has shrunk by one line, the number of lines appears not to have changed.

E.g. 40 line screen with 39 line scrolling region: LINES=39. Resize terminal to be 39 lines long. Scrolling region is gone. LINES=39 again. To the software, it looks like the same size, so it concludes that there has not been a resize. The status line is now being painted over top of the bottom row, over top of the user's input, because Basta wants to put it on row 40, which doesn't exist any more, so the cursor clamps to 39.

If Basta knows what a window size change occurred, it will not do the size comparison; in that situation it takes the slow path whereby it queries the terminal itself to determine the size. (It would be undesirable to do that for each update, because sending queries to the terminal is dodgy. If the user is typing rapidly, the terminal response can get mixed up with their keystrokes, and there can be a noticeable delay in getting a response from the terminal over laggy remote connections.)

Is there any clever way to know that the terminal has changed (or at least suspect it with a reasonably low false positive rate), in the absence of having received the WINCH trap, due to having been in the background, without talking to the terminal?

Answer 1

Is there a reason basta.query_terminal_lines doesn't work?

Or, for those who haven't read the "basta" code:

Is there any reason you can't: save the cursor position in the terminal (ESC 7), move the cursor to the bottom row (ESC [ 9 9 9 9 ; 9 9 9 9 H), query the cursor position (ESC [ 6 n), restore the cursor position (ESC 8), and then read the escape sequence sent by the query?

This turns out to be a costly by effective way to get the current screen size when one has changed the internally stored values. Part of why this works is that the explicit cursor movement ignores the scrolling region on ansi/xterm/... style terminals. (I think I've used a different terminal that didn't.)

Note that the number 9999 needs to larger than the screen could be. With a new 7680 × 4320 display, and the "nil2" font, the window could be 2160 lines and 7680 columns. (And that doesn't count Xinerama, or windows too large to display.) 9999 may not be large enough for long.