jimr@hcrvx2.UUCP (Jim Robinson) (09/03/86)
* 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
guy@sun.uucp (Guy Harris) (09/03/86)
> 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)
davel@hpda.UUCP (Dave Lennert) (09/05/86)
In article <2385@hcrvx2.UUCP> jimr@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@ucb-vax.ARPA [ARPA] Cupertino, CA 95014 (408) 447-6325 [AT&T]
doon@sdcrdcf.UUCP (Harry W. Reed) (09/14/86)
In article <1435@hpda.UUCP> davel@hpda.UUCP (Dave Lennert) writes: >In article <2385@hcrvx2.UUCP> jimr@hcrvx2.UUCP (Jim Robinson) writes: > >> I recently looked at the IEEE proposal to the P1003 committee on UNIX >> 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". > >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 I've been reading my copy of the P1003 proposal and I can't find any reference to setpgrp2(). The one I have was issued in April '86. Has there been a later release? And I missing something? Thanks, Harry Reed
davel@hpda.HP.COM (Dave Lennert) (09/22/86)
In article <3008@sdcrdcf.UUCP> doon@sdcrdcf.UUCP (Harry W. Reed) writes: > I've been reading my copy of the P1003 proposal and I can't find any reference > to setpgrp2(). The one I have was issued in April '86. Has there been a > later release? And I missing something? If you're reading the hardcopy, trial-use standard it's not there. The most recent distribution of the P1003 job control proposal was in the August mailing to the P1003 Working and Corresponding group (cover letter dated July 29, 1986, beginning "Dear Colleagues:"). The setpgrp2() function is described there in the proposed update to section 4.3. My earlier posting was incorrect in that the TIOCSPGRP ioctl() is really called TCSPGRP in the "Proposal for General Terminal Interface and Modem Interface" dated August 6 and contained in the same mailing. -- Dave Lennert ucbvax!hpda!davel [UUCP] Hewlett-Packard - 47UX ihnp4!hplabs!hpda!davel [UUCP] ITG/ISO/HP-UX davel/HPUNIX/UX [HPDESK] 19447 Pruneridge Ave. hpda!davel@ucb-vax.ARPA [ARPA] Cupertino, CA 95014 (408) 447-6325 [AT&T]