daves%hpcvxds@SDE.HP.COM (Dave Serisky) (12/10/88)
>I have recently noticed that there appears to have been a change >(from R2 to R3) between the semantics of xterm and controlling tty's. >In R2 both xterm and the child it exec's have a new controlling tty. >In R3 xterm has the same controlling tty as its parent and the child has >a new controlling tty. > >Was this change intentional? If so what were the reasons? > >Mark Patrick >Ardent Computer >uunet!ardent!mlp The change was intentional. I made it when I rewrote xterm's main.c code. There is no desired reason for xterm's controlling terminal to change. Normal programs don't change their controlling terminal either. The only reason why the R2 (and earlier) xterm's changed their controlling terminal when you get right down to it was because the ttyslot() function returns the /etc/utmp slot that corresponds to the controlling terminal of the process. The R2 code did extensive process group and terminal group munging so that it could call ttyslot() after which it tried to restore things. Obviously it was not completely successful as was pointed out above. When I ported xterm to SYSV (for HP-UX), I had to change all of this stuff anyway. The basic process in xterm now is: - parent open's up pty master, - parent forks(), - child open's up pty slave, - child does whatever is necessary to put itself into a new process group and make pty slave its controlling terminal, - child munges /etc/utmp entry, - child returns ttyslot() position to parent via pipes, - child exec's program. The old BSD style process group and controlling terminal munging didn't work well at all for SYSV primarily because the parent was the one who opened the pty slave. Under SYSV, if the parent had no controlling terminal, (if, for example, a setpgrp() had been done before it was fork()ed) it would then become the process leader for the terminal. Since you could not guarantee against this, it was necessary to try and force it. The result was that xterm was the process group leader for the pty and xterm's child process ran in xterm's process group. By splitting things off and having the child process do all the pty slave manipulation (including the initial open of the pty slave), it was possible to produce the desired behavior: xterm ran unmunged, xterm's child ran as the process group leader of the pty and in it's own process group. And best of all, the code was much simpler, easier to understand, and used process group and controlling terminals in the manner that the BSD and SYSV designers had intended. Kind of long and drawn out, but you asked for details... -- Dave Serisky Corvallis Workstation Operation Hewlett-Packard daves%hp-pcd@hplabs.hp.com