"Linux Gazette...making Linux just a little more fun!"

The Answer Guy


By James T. Dennis,
Starshine Technical Services, http://www.starshine.org/

(?)Detaching and Re-attaching to Interactive Background Processes

From Lawrence Tung on 16 Aug 1998

Hi, James: When I run a background interactive process, e.g. ncftp, I logout. Is it possible to reattach this process to a terminal again after I relogin?

Lawrence

(!)Look for a program called 'screen'. It's included with most distributions and it's available at the UNC repository (Sunsite) at:
http://sunsite.unc.edu/pub/Linux/utils/console
(which technically isn't the the best place for it since it isn't a "console" specific utility --- you can use it from any terminal, dial-up line, xterminal, or over telnet and rlogin sessions).
'screen' gives you the ability to multiplex a number of interactive shell sessions through a single terminal session. You reserve one keystroke ([Ctrl]+[A] by default) which is the meta key that provides access to all 'screen' functions.
Thus the key sequence [Ctrl]+[A], [D] will "detach" your currently running screen session from the current terminal connection. To re-attach later (from that terminal session or any other) you use the 'screen -r' command.
When you first start 'screen' you might first think that "nothing" happened. It normally just starts a single shell session. If you start a command (such as 'vi' or 'emacs') and use the key sequence [Ctrl]+[A], [C] you'll "create" a new session. You can now toggle between the current subsession and the most recently active one by by typing [Ctrl]+[A] twice.
You can "cycle" from one screen to the "next" (through all of them in a round robin fashion) by typing:
[Ctrl]+[A] [Space]
... and you can get to any of your subsessions (interactive windows) using the meta key ([Ctrl]+[A]) followed by a single digit. You can have up to ten 'screen' subsessions for any screen session. You can even have multiple screen sessions detached. Your 'screen -r' command will list the PID's/sockets of the sessions that you own and will let you specify the PID (socket extension) of the one you want to resume.
To send a [Ctrl]+[A] through to your applications (to move your point/cursor to be beginning of an 'emacs' line, for example) you'd type [Ctrl]+[A], [A]. (Note that the first is a "control" character and the next is just the normal, unshifted, letter).
Of course you can change the "meta" key --- but I like it just the way it is. There are the usual sorts of command line options, and there are also "colon" commands to set many parameters modes and options.
When you "detach" a screen session then all of the "windows" or "subsessions" are left running. They are not suspended (as they'd be if you used [Ctrl]+[Z] on them.
There are many other 'screen' features:
... and many others.
About the only three features I think are missing from 'screen' are:
It appears that the authors were playing with some "co-pilot" features and gave up on them. Some of the colon commands have to do with controlling in memory "access control lists" (ACL's) which are apparently preliminary support to allow multiple users, on multiple terminals to have concurrent access to one screen session (with some or all of them being "read-only" and others having full "read-write" to the session).
It is possible to do very simple two way collaboration using 'kibitz' (an 'expect' script that's included with some Linux distributions). It's a bit clunking but functional. However it does give the "kibitzer" full terminal access to your session, including the ability to kill or suspend a running program and access to your shell. Thus 'kibitz' (as it's written) should be used only to work with trusted parties (someone that you'd sit down at your keyboard with access to one of your login sessions).
It might be possible to modify 'kibitz' for read-only access. This would be conception similar to running a command like:
script /tmp/mytypescript.broadcast
... and having your 'clients' run the command:
tail -f /tmp/mytypescript.broadcast
... except that it would flushing it's buffers far more frequently. (If you actually try running the 'script/tail' pair as shown --- or you use 'screen' "log to file" feature and slap a tail -f on that file --- you'll see that a few kilobytes of buffers are not written to the tail -f process until enough other activity has occurred on that screen/subsession or shell.
By comparison 'kibitz' is writing synchronously --- it's flushing each character out to its file (which I think is actually a Unix domain socket rather than a regular file).
So, the things that I'd like to see added to 'screen' are merely a consolidation of tools that are already available, and that all seem to be completely compatible with it.
In any event, I highly recommand 'screen' --- it's the closest thing to DESQview that I've ever found for Unix.

(?)Detaching and Re-attaching to Interactive Background Processes

From Lawrence Tung on 17 Aug 1998

Hi, Jim: Thanks for your reply. I've used "screen" before. I need to start "screen" before I "detach" the terminal. right? Is it possible to reattch a process to a terminal after you relogin without starting any utilities in advance?

Lawrence

(!)Not under current versions of Linux.
Conceptually you could have a kernel feature that allowed you to do something like this ---- for example if you were using a 'streams' based terminal driver (or some custom terminal driver).
Basically the gist of it is that you have to know what you want in advance. There is no "normal" (standard or conventional) Unix/Linux mechanism for this --- so you have to either use a utility for it --- or you have to select an implementation that has "nonstandard" features.
Frankly I don't know of any Unix that does support this sort of thing (except via 'screen' of course).
As a couple of side notes:
ncftp has direct support for background and "re-dial" file fetching. Some of these are enhanced in the at ncftp.com.
If you need this sort of "attach and detach" feature for X the best I've been able to find thus far is to use the VNC Xserver and attach to it via the VNC client of your choice. Look at http://www.orl.co.uk/vnc for details.

Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 32 September 1998

[ Answer Guy Index ] phreak abandon javaterm BBS flaws doslinux resume
softwindows convert apache emulate database distrib proxy
disable DVI superblock serial permission detach cdr
rs422 modem notfound tuning libc5 startup clock ping
accounts lilo NDS 95slow nonlinux progenv cluster ftpd

[ Table Of Contents ] [ Front Page ] [ Previous Section ] [ Next Section ]