ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/21/88)
In article <10552@stb.UUCP>, michael@stb.UUCP (Michael) writes: > Problem: When windows are switched, the window that was active has all of > its keyboard input flushed. I don't like this even if it is documented, and speaking of stupid things that happen when you switch windows, there's another one that I can't stand. Switching windows causes a SIGWIND signal to be sent, apparrently to the whole process group. Usually, this is harmless, but certain programs seem to be confused by this. For example, if you bang out to a shell from the "less" program (type "!sh"), and then switch windows, less will think the shell has exited and start reading the keyboard again. This results in a big mess. I haven't figured out why less is affected by this other than to observe that the wait(2) call within system(3) is returning early with errno==EINTR. This makes sense in itself, but obviously not all programs are affected in this way, and I don't think less should be either. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/23/88)
In article <4789@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > Switching windows causes a SIGWIND signal to be sent, apparrently to >the whole process group. Usually, this is harmless, but certain programs >seem to be confused by this. For example, if you bang out to a shell from >the "less" program [ ... ] I got out the source to less and discovered that it is explicitly catching SIGWIND if it exists (so that it can find out if the window changes size while it's running, although this doesn't seem to work). Then the wait() inside system() gets aborted by the signal. That explains why less is affected when other programs aren't, but still seems bogus. Less could ignore SIGWIND before calling system(), but then it wouldn't find out about any window changes in the meantime. Perhaps it should be considered a bug in the Unix PC's system() function, since SIGWIND is a legitimate process-group-type signal that might occur, but system() only takes care of SIGINT and SIGQUIT. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.cbm.commodore.com
richard@uhccux.uhcc.hawaii.edu (Richard Foulk) (09/24/88)
} Perhaps it should be considered a bug in the Unix PC's system() function, } since SIGWIND is a legitimate process-group-type signal that might occur, } but system() only takes care of SIGINT and SIGQUIT. The system(3) library function wasn't ever intended to cover all eventualities. It was meant to be small and simple. Most fair-sized screen-oriented programs I've seen use their own version of it. There are just too many details that are dependant on the programs approach to signal handling, process control, etc. Richard
jr@amanue.UUCP (Jim Rosenberg) (09/25/88)
In article <4789@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >speaking of stupid things >that happen when you switch windows, there's another one that I can't >stand. Switching windows causes a SIGWIND signal to be sent, apparrently to >the whole process group. Usually, this is harmless, but certain programs >seem to be confused by this. For example, if you bang out to a shell from >the "less" program (type "!sh"), and then switch windows, less will think >the shell has exited and start reading the keyboard again. This results in a >big mess. Hmm. I thought that unlike most signals, the default for SIGWIND if you don't issue a signal() is SIG_IGN. If less is failing to ignore the SIGWIND then presumably it must be catching it. I haven't poked into the code for less, but this sounds like something that's fixable by hacking less. Try taking a gander at where it's catching signals. There are a lot of things about the 3b1 interface that I'm not fond of, but sending SIGWIND doesn't seem too bad to me if the default is SIG_IGN. I have a hunch that SIGWIND is used on other systems (Suns???) in ways that might not be consistent with the 3b1, though. Now what is inexcusable to me is this: if they've got all the hooks for SIGWIND why couldn't they have hacked vi so that it reinitialized curses on SIGWIND and overrode the li and co entries so that they match the size of the window??? Isn't this *JUST EXACTLY* what SIGWIND is supposed to be *FOR*?? -- Jim Rosenberg CIS: 71515,124 decvax!idis! \ WELL: jer allegra! ---- pitt!amanue!jr BIX: jrosenberg uunet!cmcl2!cadre! /
les@chinet.UUCP (Leslie Mikesell) (09/29/88)
In article <4844@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >> I have >>a hunch that SIGWIND is used on other systems (Suns???) in ways that might not >>be consistent with the 3b1, though. >Sun calls it SIGWINCH. I would guess that the signals themselves have >similar semantics, but a program has to do completely different things >once it catches one (different ioctls, etc.). I tried changing the SIGWINCHes in both JOVE and GNU emacs to SIGWINDs with no luck at making them adjust to a resized window. I didn't pursue it by looking into the ioctl semantics to see if there is a difference in the way a program finds its new window size, though. Has anyone worked on this? Les Mikesell