Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site hcrvx2.UUCP
Path: utzoo!hcrvx2!jimr
From: j...@hcrvx2.UUCP (Jim Robinson)
Newsgroups: net.unix,net.unix-wizards
Subject: P1003 System V compatible BSD-style job control
Message-ID: <2385@hcrvx2.UUCP>
Date: Tue, 2-Sep-86 20:34:29 EDT
Article-I.D.: hcrvx2.2385
Posted: Tue Sep 2 20:34:29 1986
Date-Received: Wed, 3-Sep-86 00:47:47 EDT
Organization: Human Computing Resources, Toronto
Lines: 14
*
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 one system call that I thought
might do this 'setpgrp2' quite clearly says that this "function does not
affect the process's terminal affiliation". Assuming that the words
"association" and "affiliation" are interchangeable in this context, then
it would appear that this call does not do as I had thought it might.
Am I missing something, or is this correct wrt 'setpgrp2'. If the latter
is true, then what means is to be used to perform terminal association?
J.B. Robinson
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!hplabs!hpda!davel
From: da...@hpda.UUCP (Dave Lennert)
Newsgroups: net.unix,net.unix-wizards
Subject: Re: P1003 System V compatible BSD-style job control
Message-ID: <1435@hpda.UUCP>
Date: Thu, 4-Sep-86 19:40:24 EDT
Article-I.D.: hpda.1435
Posted: Thu Sep 4 19:40:24 1986
Date-Received: Wed, 10-Sep-86 20:22:46 EDT
References: <2385@hcrvx2.UUCP>
Reply-To: da...@hpda.UUCP (Dave Lennert)
Lines: 65
In article <2...@hcrvx2.UUCP> j...@hcrvx2.UUCP (Jim Robinson) writes:
> 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 one system call that I thought
> might do this 'setpgrp2' quite clearly says that this "function does not
> affect the process's terminal affiliation".
There are two ways that a process can be "related" to terminal (in the
context of job control). First, a process can have a controlling
terminal (u_ttyp and u_ttyd point to the tty struct in bsd). (This is
what open("/dev/tty") follows.) Second, a terminal can have a tty group
ID (t_pgrp) which is the process group to send keyboard signals to.
Job control introduces the concept of foreground/background. A process
is in the background with respect to its controlling terminal if the
process group of the process (p_pgrp) does not match the tty group ID
(t_pgrp) of its controlling terminal (u_ttyp). Otherwise it is in the
foreground.
In the P1003 proposal, setpgrp2() can change the process group (p_pgrp)
associated with a process, either the calling process or another. (It
is basically bsd's setpgrp() with some extra security.) This does not
effect whether the process has a controlling terminal (i.e., it does not
alter u_ttyp); unlike System V's setpgrp() which disassociates the
calling process from its controlling terminal.
Also, the termios P1003 proposal contains the specification for the
TIOCSPGRP ioctl() which is necessary for job control. TIOCSPGRP alters
what the tty group ID is for a terminal. (Again, it is basically from
bsd with some extra security.) This effects which processes receive
keyboard signals; it also effects which processes (having this terminal
as their controlling terminal) are in the foreground or background.
Again, this does not effect whether or not a process has a controlling
terminal (u_ttyp, u_ttyd are left unaltered).
Bsd also contains the TIOCNOTTY ioctl() which disassociates the calling
process from its controlling terminal. (Much like System V's setpgrp()
but without the other side effects.) TIOCNOTTY is *not* part of the
P1003 job control proposal as it is not necessary for job control.
I am aware of no programmatic call in bsd that assigns a particular
terminal to an arbitrary process as its controlling terminal (sets
u_ttyp, u_ttyd).
Have I misunderstood your question?
(BTW, read "A System V Compatible Implementation of 4.2BSD Job Control"
by yours truly in the Summer 1986 Atlanta USENIX Proceedings for more
background information on bsd job control and how it was altered for the
P1003 proposal.)
Dave Lennert ucbvax!hpda!davel [UUCP]
Hewlett-Packard - 47UX ihnp4!hplabs!hpda!davel [UUCP]
19447 Pruneridge Ave. hpda!da...@ucb-vax.ARPA [ARPA]
Cupertino, CA 95014 (408) 447-6325 [AT&T]