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