[unix-pc.bugs] Bug report--window driver 3.51 bogosity during window switch

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