Linux, Unix, /etc

Danger Will Robinson! You are now entering a condescending Unix user zone!

Screen

introduction: what and why

what is screen

why screen?

In this age of high-resolution bitmapped displays and sophisticated graphical user interfaces, why bother with screen? Well, speaking for myself, I like big clear text on my screen, and the console still beats a hi-res graphical display at that. I'm a writer, I care about the words, not what they are going to look like — so I don't need a bit-mapped display to show fancy fonts, etc — though it can occasionally be handy for print previews or looking at images ,most of the time in front of the screen in spent reading and wrting. I need a display that's easy on the eyes and displays the letters clearly and distinctly. It takes a really good (read: expensive) display to make that "like paper" effect actually come off; on my 15" multisync, the fonts look like the compositor had a few too many the night before, and I get eye strain. So, linux console it is then. But don't I then miss out on all the great features of a GUI? Cut and paste, multiple windows? Not if I use screen.

cut & paste

Indeed, it isn't necessary to use screen to get cut & paste on the linux console. But I find cutting and pasting with the mouse, à la selction or its replacement gpm, is a pain. Screen gives me simple keystroke commands based on the vi command set to select areas of text and paste them into other screen displays. Hitting ^A^[ (that ^[ is Esc, by the way, or control-[, either will do, and I usually prefer the latter, being a "keep the fingers on the home keys" man) brings me into selection mode. I can then use a wealth of vi-like navigation keystrokes to mark the text I want. That done, I hit Space, and the selected text is copied into a buffer. I could also have hit to append the selected textx to the buffer — the default action with Space, is to overwrite the existing contents. Text from the paste buffer is fed to the stdin queue of the current window whenever I hit ^A^].

multiple windows

Multiple console displays are of course possible using just the linux console driver. How many are available depends on your distribution. By default on slackware Alt-1 to Alt-12 each birngs up a different console display. This is all well and good. However, screen makes use of the "virtual terminal" facilities of all modern Unices, to allow more than one virtual terminal to be attached to one physical terminal. Switching between windows, or screens as we call them, is done with a few simple keystrokes. The advantage of this way is that it gives one a sort of desktop, with cut and paste between screens.

flexibity

Work done for the day, I can detach my screen session, log out, and go to bed. The next day, I can log in, and, with screen -r (for "resume"), my screen session is restarted with everything just as it was. This goes further: I can detach a screen seesion from one terminal; then, days or weeks later, uptime permitting, I can loging and re-attach from another terminal in another room, buidling or country!

use with dumb terminals

Screen can emulate a vt100 even on older, more limited terminals. OK, so who uses terminals nowadays? Well, they have their uses. I've always thought it odd that to have just one screen and keyboard attached to the computer, so that anytime we want to use the machine, we have to go to a special room, usually one dedicated to the function. It isn't a washing machine, folks! A few dumb terminals got dirt cheap or from the back of a skip plus a few lengths of serial cable, and hey presto! access to your machine from every room in the house! Without screen, this owuld still be useful, but limited; with screen, you can detach your screen session in the kitchen, go into the library and reattach the same session, taking up where you left off, with all your different programs still running. A hell of a lot more convenient that sticking a few jobs into the background, your only choice otherwise.

screen as a login shell

Hmm, haven't tried this.

registers

One little-known feature of screen — at least, I've been using screen for years, and only discovered it the other day — is the existence of "registers". You can pack stuff into a register in advance, and then paste the contents into the current window at a keystroke whenever required. There seem to be 36 — a-z, and 0-9. I'm not sure how much a register can hold. They are very handy for storing frequently-typed strings: userids and passwords for logging on to web pages and the like.

Storing is done from the screen command line by

register [reg] [value]

The same command can be used in your .screenrc file.

Retrieval is done by

paste [reg]

which is a bit clunky to type, but that is easily fixed by an additional key-binding which can also be put in your .screenrc file:

bind P paste

By default, ^AP goes to previous screen, but since ^Ap and ^A^P do this as well, I think we can spare P for this very useful function.

A truly great unsung feature of screen.

hardcopy

I can get a text files containing the contents of the current screen by hitting ^Ah. This will be written by default to a file hardcopy.<window-number> in the window's default directory e.g. /tmp/hardcopy.2. Succesive hardcopies from the same screen will be appended to this file. This behaviour is controlled by a screenrc option, "hardcopy_append on|off". The destination of the hardcopy file can also be set using the screenrc option "hardcopydir <directory>".

^AH, on the other hands, starts logging the current window to the file screenlog.<window-number>. The keystroke acts as a toggle: ^AH again switches logging off. This logging is only useful when the termainl is not in raw mode, so you can't use it to record a vi session, for example. But for ordinarly text input and output at the command line, it's fine. The screenrc option "logfile <filename>" determines the filename to use for such a screenlog.

other stuff

))) :screen <cmd> runs command and then terminates the screen, saving the bother of launching another shell. For example, this little script

#!/bin/sh
#baselynx
export http_proxy=http://localhost:80/
exec lynx file://localhost/home/paul/.handy.html

when run by

:screen baselynx

starts a new virtual terminal running lynx. when the user exits from lynx, the virtual terminal also closes down.

status line

On terminals that support it, for example the linux console, screen can make use of the hard status line. Right now, my hard status line looks like this:

9:13 Sun 03 Feb 2002. Window 2 (articles)

Example init file

activity "You hear noises in window %n"
autodetach on
bell "You hear noises in window %n"
bind 
bind x
bind 
bind k
bind 
defflow off
deflogin off
defmonitor off
defwrap on
hardcopy_append on
hardcopydir /tmp/
hardstatus on
hardstatus lastline
defhstatus 'c D d M Y. Window n (t).'
nethack on
shell -$SHELL
startup_message off
vbell off
verbose on
screen -t main 0

[back to Linux, Unix, /etc]