P1003 System V compatible BSD-style job control

[Dave Lennert]

In article <2385 at hcrvx2.UUCP> jimr at 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!davel at ucb-vax.ARPA         [ARPA]
    Cupertino, CA  95014        (408) 447-6325                  [AT&T]