Path: utzoo!mnetor!uunet!mcvax!unido!tub!cabo From: cabo@tub.UUCP (Carsten Bormann) Newsgroups: comp.unix.questions Subject: Re: inheriting processes from other ttys Message-ID: <358@tub.UUCP> Date: 21 Feb 88 16:24:17 GMT References: <1707@phoenix.Princeton.EDU> <17987@topaz.rutgers.edu> <352@tub.UUCP> <10091@ulysses.homer.nj.att.com> Reply-To: cabo@tub.UUCP (Carsten Bormann) Organization: Technical University of Berlin, Germany Lines: 77 Keywords: screen poor man's windowing Summary: Oliver has done it. In article <10091@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: () In article <352@tub.UUCP>, cabo@tub.UUCP (Carsten Bormann) writes: () > () > The plan was to do it in two steps: () > () > 1) Implement detaching from a ``screen'' process and attaching to it () > from a different terminal of the same type. () > 2) Enhance ``screen'' to be able to change terminal types mid-river, which () > in combination with (1) would allow you to e.g. detach from an h19 () > and attach from a vt100 (as long as the screen dimensions and other () > critical parameters remain the same). () () I've thought of doing this also. You now can all stop thinking about step 1, my posting (and the perceived need by the growing ``screen'' user community :-) motivated Oliver to implement it. We are, however, not yet completely happy with the solution: Making ``screen'' detachable involves always having two ``screen'' processes. The parent process essentially is there to make the login shell (or /etc/init for the daring) wait for the next detach command. The child process contains the functionality of screen as it is now. There is no way to unite the two processes for the following reasons: 1) The detach command must make screen terminate (at least from the point of view of the shell or /etc/init). The standard way to handle this in the daemon world would be to fork and have the parent exit; unfortunately there is no way to inherit the parental relationship screen had with the programs in the windows to the new child process. Therefore, the child process must manage the forking of the window processes from the outset; for minimum change, Oliver gave it the entire functionality. Now if UNIX provided a way to bequeath children to a new child... 2) The attach command must be a command callable from the shell (currently it is called screen -r, r for resume). This command must stay alive as long as the old child process is handling the terminal; otherwise the shell would compete with screen over the tty. Now if UNIX provided a primitive to replace the contents of a process with a different process (exec from a running process)... The new parent process of the screen utility does not wake up except for implementing Quit, Detach, and Suspend, so it is not too much overhead; on the other hand, having the entire thing in one process as before would have been more aesthetically pleasing (and would provide less potential for strange states where the two processes do not agree what's up). Oliver probably will make available a patch to the last version of screen when we have had a week or so of alpha-testing. When step 2 has been implemented and other cleanup has been done, a new posting to comp.sources.unix might be in order. A few parting comments on Chris' posting: () One probelm with this approach is speed, of course. The solution is to buy a computer that is fast enough. Seriously, the main reason Oliver does not use his own program too much is that it slightly slows down terminal I/O on this box. This does not discourage me the least... () Another thing is that it would be much easier to impliment () using the terminfo database, instead of termcap, but it's () not available under BSD, or Xenix (versions I've used). When System V release N includes a pty driver (or equivalent functionality, such as a STREAMS-based terminal driver), we can talk about moving ``screen'' to System V. Until then, tough luck (and no terminfo). Regards, Carsten Bormann -- Carsten Bormann, Communications and Operating Systems Research Group Technical University of Berlin (West, of course...) Path: ...!pyramid!tub!cabo from the world, ...!unido!tub!cabo from Europe only.