Timeline for Detectng missed SIGWINCH in Bash extension, when apparent terminal size has not changed
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 11 at 2:51 | vote | accept | Kaz | ||
| Feb 11 at 2:04 | answer | added | David G. | timeline score: 2 | |
| Feb 11 at 1:35 | comment | added | Kaz | @DavidG. Sure. It provided the key insight: the project is already interrogating the terminal, with a bit of care, for the current line which is exactly how you find the true size, when combined with a cursor motion. I've since made more changes. There is now a basta.fullscreen function which you can run commands that will use the whole terminal, e.g. alias vim=basta.fullscreen vim and then restore the status line. | |
| Feb 10 at 23:06 | comment | added | David G. | should I turn that one-line question into an answer? | |
| Feb 10 at 23:05 | comment | added | David G. | Looking at that diff... the use of stty sane is probably a bad idea. You are supposed to save the output of stty -g, and then use that as the parameter to restore things. (I know, another process. :-( ) And of course, bash probably doesn't want things sane anyway. (sane is inconsistent with command line editing.) If you can work out when bash switches, and to what, you might be able to skip the sane all-together. | |
| Feb 10 at 18:15 | comment | added | Kaz | @DavidG. this new commit fixes it for me. I will do some additional time-based hacks to make it more efficient (e.g. avoid doing it if it was already done in the last 5 seconds. Newer bashes have $EPOCHTIME so you don't have to fork off a subprocess to get time. | |
| Feb 10 at 9:08 | comment | added | Kaz | @DavidG. Oh, it does. It's just a heavy hammer; it has to talk to the terminal and get a response. Ah, but /slapforehead/ ... the basta.get_cur_line function it relies on is called by basta.check_cursor also . That function is called for every command prompt. It avoids doing that check when there is pending TTY input. Maybe something can be rigged in basta.check_cursor to detect the situation. After checking for a bad cursor position and correcting it if necessary, we could then do the terminal size check. | |
| Feb 9 at 4:00 | comment | added | David G. | Is there a reason basta.query_terminal_lines doesn't work? | |
| Feb 8 at 20:24 | comment | added | Kaz | @DavidG. However, curses-based (and other) programs will overwrite the area anyway. Here is why: when they issue a "clear to end of screen" escape sequence, the terminal ignores the scroll-protected area and wipes it. So that is more or less moot. Of course programs that don't clear to EOS don't cause this problem. A lot of full screen programs do, though. | |
| Feb 8 at 19:52 | comment | added | David G. | Changing stty rows <value> means that curses based program don't think they can overwrite that area. Good&Bad. But a terminal reset will still mess things up. I could see sending a SIGWINCH to all your ancestor bashes with every command to refresh things. Probably better to used passed-down variables to rebuild all the lines, but that goes wrong if you suspend the child bash and change the context in the parent. I will admit I find the idea of a status line intriguing,though I prefer tcsh. I hate to say it, but I suspect the only reliable solution is a mini-screen, that does its own pts. | |
| Feb 8 at 19:17 | comment | added | Kaz | No, LINES and stty rows from termios match all the time. We subtract 1 from both when setting up the scroll-protected status line. It's an interesting idea not to have them match (keep tracking physical size with termios). We may somehow be able to get away with it. | |
| Feb 8 at 13:35 | comment | added | David G. | in screen, the command screen -X msgwait 0 ; screen -Q info ; screen -X msgwait 5 will return the real size, plus some other stuff. The downside is it changes the "msgwait" value, and on some older versions can get stuck. screen can be detected by $STY | |
| Feb 8 at 12:23 | comment | added | David G. | Well, you could try TIOCGWINSZ - it works with xterm but not screen. You might try catching SIGTSTP as well (though I admit people might be more likely to do "kill -STOP". You could consider aliasing kill to change STOP to TSTP :-) ) | |
| Feb 8 at 12:06 | comment | added | David G. | Oh... you are changing THAT too. Then maybe that won't help. | |
| Feb 8 at 12:00 | comment | added | David G. | 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. | |
| Feb 8 at 1:17 | comment | added | Kaz | @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! | |
| Feb 8 at 1:14 | comment | added | Kaz | @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. | |
| Feb 8 at 0:00 | comment | added | David G. | Have you considered reading the terminal's line count? It is a simple ioctl() call. | |
| Feb 7 at 19:54 | history | asked | Kaz | CC BY-SA 4.0 |