rjchen@phoenix.UUCP (02/11/88)
Say my terminal freezes while running a program. So I log on somewhere
else. Question: Can I get the process transferred from the frozen
terminal to my new (good) one? That is, if the process were an editor,
I should be able to resume my editor session on the new terminal with
no ill effects. (Presumably, after I transfer the process, I can kill
the login session on the hung terminal.)
If it makes any difference, I use the C-shell.
--
Raymond Chen UUCP: ...allegra!princeton!{phoenix|pucc}!rjchen
BITNET: rjchen@phoenix.UUCP, rjchen@pucc
ARPA: rjchen@phoenix.PRINCETON.EDU
"Say something, please! ('Yes' would be best.)" - The Doctorron@topaz.rutgers.edu (Ron Natalie) (02/12/88)
There is no good way to subsitute one terminal file descriptor for another. Some programs may be smart enough (like emacs) to switch for you, but this is the exception rather than the rule. The only practical way of doing this currently in UNIX, is to keep a psuedo- terminal of some sort as the tty file descriptor and switch that pseudo-terminal to real terminal mapping around. This is a generalization of the System V xt/sxt system. This provides you the attach/detach features that some of the nicer DEC operating systems provided (TOPS-20 anyone?). I have a user mode version of this for 4BSD (actually anything with Berkeley like pty/tty pairs) that I did as a proof of concept for a later in-kernel implentation, but I've never gotten around to finishing the in-kernel project. -Ron
cabo@tub.UUCP (Carsten Bormann) (02/15/88)
In article <17987@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes:
() [...]
()
() This provides you the attach/detach features that some of the nicer
() DEC operating systems provided (TOPS-20 anyone?). I have a user
() mode version of this for 4BSD (actually anything with Berkeley like
() pty/tty pairs) that I did as a proof of concept for a later in-kernel
() implentation, but I've never gotten around to finishing the in-kernel
() project.
I don't know if we really need this in the kernel right now.
We have contemplated adding a detach/attach feature to ``screen''
(Oliver Laumann's poor man's window system), but didn't get around
to it yet. Maybe Ron's code can be integrated. Any volunteers?
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 don't think I would want to put step 2 into the kernel...
--
Carsten Bormann, <cabo@tub.UUCP> <cabo@db0tui6.BITNET> <cabo@tub.BITNET>
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.cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) (02/18/88)
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. Another enhancement is to have the windowing protocal have it's own escape sequences, both for input and for output, and to map them to the sequences of the host terminal. This would allow the detach/attach code to be terminal independant, and would allow the windowing software to run on both character oriented terminals, and on bit mapped terminals. One probelm with this approach is speed, of course. 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). Chris Calabrese AT&T Bell Laboratories ulysses!cjc
rjchen@phoenix.Princeton.EDU (Raymond Juimong Chen) (02/18/88)
All this discussion is well and good, but I was looking for something
much simpler. (This isn't comp.unix.wizards, right?)
Assume that I'm logging in with an identical terminal. Is there a way
to inherit the process? Or is all this discussion saying "No, but here's
a proposal for how it could be done"?
--
Raymond Chen UUCP: ...allegra!princeton!{phoenix|pucc}!rjchen
BITNET: rjchen@phoenix.UUCP, rjchen@pucc
ARPA: rjchen@phoenix.PRINCETON.EDU
"Say something, please! ('Yes' would be best.)" - The Doctorcabo@tub.UUCP (Carsten Bormann) (02/22/88)
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, <cabo@tub.UUCP> <cabo@db0tui6.BITNET> <cabo@tub.BITNET> 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.
mouse@mcgill-vision.UUCP (der Mouse) (03/13/88)
In article <1707@phoenix.Princeton.EDU>, rjchen@phoenix.Princeton.EDU (Raymond Juimong Chen) writes: > Say my terminal freezes while running a program. So I log on > somewhere else. Question: Can I get the process transferred from > the frozen terminal to my new (good) one? [and in your signature I find the appropriate line] > "Say something, please! ('Yes' would be best.)" - The Doctor Gee, I don't know. What sort of system are you using? On a BSD system, I can say fairly confidently "no". This could be hacked in, but it would require either kernel support which isn't there in stock systems or a strange sort of terminal session multiplexor, something like what someone was posting about `screen'. > That is, if the process were an editor, I should be able to resume my > editor session on the new terminal with no ill effects. Let's just hope the terminal type is the same as on the old terminal! der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
ron@topaz.rutgers.edu (Ron Natalie) (03/25/88)
Actually, I have a program that sort of emulates the DEC-20 attach/detach feature. I prototyped it in user mode with the hope that someday I would get around to putting it in the kernel. What it does is snatch a pty for your session and map that to a regular hard tty line. If you explicitly detach, hang up the phone, or are inactive for a specified period of time, the pty releases the hard tty line and goes into a dormant state. A simple command from another hard terminal remaps it to the new terminal. -Ron
anw@nott-cs.UUCP (03/29/88)
In article <990@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >In article <1707@phoenix.Princeton.EDU>, rjchen@phoenix.Princeton.EDU (Raymond Juimong Chen) writes: >> That is, if the process were an editor, I should be able to resume my >> editor session on the new terminal with no ill effects. > >Let's just hope the terminal type is the same as on the old terminal! In any half-way decent editor (or other terminal-dependent program), there should be a command to reset the terminal type. There certainly is in the Nottingham version of "ed"; and very useful it is when editing termcap entries, in particular. -- Andy Walker, Maths Dept, Nottm Univ, UK. anw@maths.nott.ac.uk