Path: utzoo!utgpu!water!watmath!uunet!cbmvax!ditto From: ditto@cbmvax.UUCP (Michael "Ford" Ditto) Newsgroups: unix-pc.bugs Subject: Re: Bug report--window driver 3.51 bogosity during window switch Summary: Not quite as bogus as I thought Keywords: bogus input flushing and signal sending Message-ID: <4805@cbmvax.UUCP> Date: 23 Sep 88 06:57:19 GMT References: <10552@stb.UUCP> <761@rush.cts.com> <10581@stb.UUCP> <4789@cbmvax.UUCP> Reply-To: ditto@cbmvax.UUCP (Michael "Ford" Ditto) Organization: Commodore Technology, West Chester, PA Lines: 25 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