Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: mod.std.unix P1003 job control proposal (Brett Galloway)
Message-ID: <6369@ut-sally.UUCP>
Date: Mon, 17-Nov-86 13:50:09 EST
Article-I.D.: ut-sally.6369
Posted: Mon Nov 17 13:50:09 1986
Date-Received: Mon, 17-Nov-86 21:17:55 EST
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 35
Approved: jbc@sally.utexas.edu

References:


>From nsc!hplabs!hpda!hpisoa1!davel@pyramid.UUCP Wed Nov 12 16:57:34 1986
Cc: gorodish!guy@sun.UUCP
Date: Wed, 12 Nov 86 10:42:53 -0800

> guy@sun.com (Guy Harris) writes:
> > 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".  

It is true that vhangup() does not break any documented behavior in 
System V or the SVID.  However, the System V implementations I am familiar 
with (mainly ATT VAX releases) allow access to open login tty file 
descriptors after logout (/dev/tty is the exception).

Again, vhangup() is, in my opinion, preferable for security reasons.  I
do not consider the alternate behavior present in at least some System V
ports worth requiring.  

> "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, ...

I'm curious; could you list some of the System V implementations which 
disallow access to the login tty (via, e.g., stdout, not /dev/tty) after
logout?  I.e., System V's that have vhangup()-like behavior?

-Dave Lennert   HP   ihnp4!hplabs!hpda!davel


Volume-Number: Volume 8, Number 55