mod.std.unix P1003 job control proposal

[Moderator, John Quarterman]

From: guy at sun.com (Guy Harris)
Date: Mon, 3 Nov 86 00:39:00 PST

> > > 	     If	the process is a session process group leader, the
> > > 	     SIGHUP signal may be sent to each process that has	a
> > 			   ^^^ should be replaced by the word "will"
> > > 	     process group ID equal to that of the calling process;

> "May" is used here to allow 4.2 systems to conform.  4.2 does not
> send SIGHUP on process group leader death.

4.2 also doesn't have the notion of a "session process group leader".
However, when the moral equivalent of a "session process group leader" dies
in 4.2, 99.99% of the time it's a login shell, and "init" proceeds to do a
"vhangup" which - sends a SIGHUP!

> vhangup() is indeed desirable.  It is not required in POSIX because it is 
> not supported on System V and, indeed, breaks System V compatiblity.

Only if you define "System V compatibility" as "behaves exactly the same as
some particular implementation of System V".  "vhangup" does two things; it
sends a SIGHUP to the process group of the terminal in question (which is,
in fact, similar to what S5 does automatically) and it invalidates file
descriptors that refer to the terminal.

Some System V implementations do not do this, although they *do* clear the
terminal's process group, which causes all subsequent references to that
terminal through "/dev/tty" to get an error.  As such, the evidence
indicates that the reason they don't generally invalidate references to the
controlling terminal is *not* that they intended to leave such references
valid, but that they just didn't bother.

The only programs *I* can think of that would want to be able to reference
the terminal they were started from, even after the user who started them
logged out, are not the sort of programs I would like to have running on any
machine I'm involved with.  They tend to be called things like "Trojan
horses".

Volume-Number: Volume 8, Number 20