Skip to main content

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

16
  • Have you considered reading the terminal's line count? It is a simple ioctl() call. Commented Feb 8 at 0:00
  • @DavidG. Didn't you get the memo? POSIX standardized this with tcgetattr in <termios.h>. We are a shell script, so our interface to the line count in the kernel is stty -a which dumps out info like rows 40 cols 80. In the problem situation, this doesn't help; the value matches what's in $LINES and also jibes with the previously known value that the script knows about. I.e. the size appears to be the same, though the terminal is smaller and we lost the scroll-protected line. Commented Feb 8 at 1:14
  • @DavidG. E.g. before we went to the background due to the execution of a command, we had a 42 line window, of which 1 line was protected from scrolling. stty -a would report rows 41, and LINES was 41. While we are backgrounded due to some program running, the window is resized to 41 lines. When the program terminates, we have rows 41 and LINES=41. But that's the full size of the window; the scroll-protected line is gone! We didn't get a SIGWINCH, and the sizes look the same. Oops! Commented Feb 8 at 1:17
  • 1) That tcgetattr() is the TCGETS ioctl call. 2) it will report the unreduced number of lines. E.g. before you went into background, you had LINES=41 and stty rows 42. After background you had LINES=41 and stty rows 41. 3) This change you can detect, without needing any signal. Commented Feb 8 at 12:00
  • Oh... you are changing THAT too. Then maybe that won't help. Commented Feb 8 at 12:06