Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix,net.unix-wizards
Subject: Re: P1003 System V compatible BSD-style job control
Message-ID: <6840@sun.uucp>
Date: Wed, 3-Sep-86 16:05:17 EDT
Article-I.D.: sun.6840
Posted: Wed Sep  3 16:05:17 1986
Date-Received: Thu, 4-Sep-86 04:11:56 EDT
References: <2385@hcrvx2.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 37
Xref: mnetor net.unix:5360 net.unix-wizards:7764

> I recently looked at the IEEE proposal to the P1003 committee on UNIX 
> standards re a System V compatible BSD-style job control mechanism (#P.047)
> and it all seemed quite reasonable except for the fact that I could not
> discern whether there existed a means of associating an arbitrary process
> with the terminal. (BSD uses an ioctl).

The P1003 proposal actually consists of the job control stuff and stuff in
the "termios" proposal; the latter includes a TCSPGRP "ioctl" that works
pretty much like the 4BSD one (with some extra permission checks).

> The one system call that I thought might do this 'setpgrp2' quite clearly
> says that this "function does not affect the process's terminal
> affiliation".

"setpgrp2" is the 4BSD "setpgrp", renamed so that it doesn't collide with
the S5 "setpgrp".  Again, modulo extra permission checks, it does just what
the 4BSD "setpgrp" does.  The bit about "not affecting its terminal
affiliation is true, but then it's true in 4BSD also.  "setpgrp2" will not
affect a process' "controlling terminal".  The P1003 "termios" proposal's
definition of the "controlling terminal" of a process amounts to "the
terminal that '/dev/tty' refers to in that process", not "the terminal that,
when the interrupt character is typed, sends a SIGINT to that process."

A terminal may have a process group associated with it; all signals
generated by that terminal (with the possible exception of the S5R3 SIGPOLL
signal) will be send to that process group.  If a process does a "setpgrp"
call, that process becomes the leader ("session process group leader") of a
new process group, whose process group ID is the same number as the process
ID of the process doing the "setpgrp".  If that process has a controlling
terminal (i.e., a "/dev/tty"), it no longer has one after the "setpgrp".  If
it subsequently opens a terminal, that terminal becomes its controlling
terminal and the newly-created process group becomes the terminal's process
group.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)