On 5/22/14, 1:16 AM, Linda Walsh wrote: > > > Chet Ramey wrote: >> On 5/20/14, 8:28 AM, Egmont Koblinger wrote: >>> Hi, >>> >>> Execute this in an interactive bash and then resize the window: >>> trap 'stty size' winch >>> >>> In bash-4.2, the trap was executed immediately upon resize. In >>> bash-4.3, it is delayed until the next keypress. >> >> http://lists.gnu.org/archive/html/bug-readline/2014-05/msg00005.html > --- > And if the window is just displaying something -- running a shell script, > when will it get the resize event so it can update it's display?
This is not part of the discussion about readline, but the answer is the same as it was before: the shell will receive the signal immediately and run any traps after the current foreground command exits. > I.e. a window resize can easily happen when no key press is in sight, > Seems like deferring it and at least calling it off a timer. Let me go through how signal handling works. Maybe that will make the current question clearer. 1. SIGWINCH arrives during a read(2) 2. The readline signal handler is executed and sets a flag noting that it received SIGWINCH. It also calls the application's SIGWINCH handler, if one is installed, to allow it to do the same. 3. Since SIGWINCH is not one of those signals that interrupts system calls, the read(2) is restarted. When it completes -- that is, when a key is pressed and read returns data -- readline handles the SIGWINCH. Handling the signal includes updating the internal state about the screen size, performing any needed redisplay, and calling an application-specified signal hook. In bash, that hook is what runs the traps. The difference between bash-4.2 and bash-4.3 (and readline-6.2 and 6.3) is that bash-4.2 did steps 2 and 3 in a signal handler context. This has always been unsafe, but is now causing problems with the kernel and libc. The most you can safely do in a signal handler is to set a flag (ideally of type sig_atomic_t). There are functions that are `signal safe' and that you can run in a signal handler, but they are not particularly useful in this case. Even a longjmp out of a signal handler is dangerous and can lead to problems. glibc is particularly bad -- it has all kinds of internal private state that has to be preserved in the library itself, like locks around memory allocation functions, which is not signal-safe. Bash-4.3 and readline-6.3 both go to considerable lengths to avoid running aribitrary code (e.g., parsing and executing traps) in a signal handler context. Further complicating things is the fact that there is not any portable way to specify that SIGWINCH should interrupt system calls. There is the SA_RESTART flag that says *not* to fail with EINTR, but there is no portable flag that has the opposite effect. (You don't want SIGWINCH to interrupt system calls anyway; it's supposed to be transparent.) > But it sounds like my winch handler that would tell me the size of > a resized screen will now be broken. I told you it would need to be changed almost a year ago: http://lists.gnu.org/archive/html/bug-bash/2013-06/msg00119.html > The whole point was to resize and it would update and tell you the size > when you finished moving. If you have to wait to type keys each time, that > sorta defeats the point. > > The previous version said this (checkwinsize): > If set, bash checks the window size after each command > and, if necessary, updates the values of LINES and COLUMNS. > > Wasn't checking the window size after each command safe? Yes, and it still is. This has not changed. It isn't really germane to this discussion. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
