Power Sessions with Screen

Screen is a terminal multiplexer that allows you to manage many processes through one physical terminal. Each process gets its own virtual window, and you can bounce between virtual windows interacting with each process. The processes managed by screen continue to run when their window is not active.

Thus far, the screen features described aren't all that exciting or new. In fact, there already are X11 terminal applications that provide this functionality (konsole and multi-gnome-terminal). What differentiates screen from the others are some of the core features screen provides.

Screen offers the ability to detach from a session and then attach to it at a later time. When detached from a session, the processes screen is managing continue to run. You can then re-attach to the session at a later time, and your terminals are still there, the way you left them.

Screen also maintains individual, searchable scrollback buffers for each of the windows it manages. You can perform traditional “enter the search term and I'll find it for you” searches as well as incremental searches. This is such an obvious feature, it's surprising that more terminal emulators do not offer it.

Other notable features of screen are configurable key bindings, utf8 and multibyte charset support, multi-attach, configurable input and output translation, input and output filter, multi-user support with access control lists (ACLs) and logging.

Before actually running screen, it's important to understand how to interact with it. Screen sends all entered text to the current window, with the exception of the command character. The default command character is Ctrl-A (press the Ctrl and the A key at the same time). The screen man page uses C-, Emacs style, to mean Ctrl-.

The command character is used to notify screen that you'd like to control screen itself, rather than the application in the current window. The key pressed after the command character designates which screen command you would like to perform.

Some of the more useful commands and their key bindings are shown in Table 1.

Table 1. Commands and Their Key Bindings

For many of the commonly used commands, the control version of the key is also bound to the command. An example of this is Ctrl-A C and Ctrl-A Ctrl-C to create a window.

To send Ctrl-A to an application without screen intercepting it, you can press Ctrl-A A. The command character can be changed to an alternate key if you wish. Typically Emacs users change the command character to Ctrl-B by adding escape Bb to their .screenrc. The following examples use Ctrl-A because that is the default.

As you might expect, .screenrc is the per-user configuration file in your home directory, and /etc/screenrc is the system-wide configuration file that applies to all users.

Now that you understand the fundamentals of interacting with screen, we can step through screen fundamentals using a typical screen session as an example. Probably the most typical use of screen is to control terminals on a remote machine on which you have a shell login.

So, for those of you playing along at home, log in to a remote host that has screen installed. If you don't have a remote host to ssh to, you can install screen and ssh to localhost. Packages for screen are available for most distributions.

You're now sitting at the shell prompt on the remote machine. Type screen at the prompt. You should see a splash screen showing some information explaining that screen is under the GPL, where to report bugs and so on. You can press the spacebar to bypass this screen (you can disable this splash screen permanently with startup_message off in your .screenrc). Next, you should arrive at another shell prompt, this one running inside of screen.

The new shell running inside of screen should behave like your first shell would. If you do a printenv, you may notice a few new environment variables set. Screen sets TERM to screen—each screen window provides its own vt100-compatible virtual terminal. The variable WINDOW is set to the virtual window number, and the variable STY is set to your session name. I'll explain more about those last two later.

So far, this single shell works exactly like you're used to working on a remote machine. For the sake of this example, say we are downloading the current version of screen (as of this writing, screen 3.9.13) from the screen distribution site at ftp.uni-erlangen.de/pub/utilities/screen. While this file is downloading, you decide to use your spare time to clean up your home directory. If you weren't using screen, you'd have to open another xterm and ssh to the remote machine. With screen, a simple Ctrl-A C will create a new screen window with a new shell process.

Thus far, you have an FTP client and a shell busily tidying up your home directory. You can check on your download in the original FTP window by using Ctrl-A P to go to the previous window. You can get back to your shell with Ctrl-A N.

When you check on your download, it's not finished (screen doesn't take that long to download, but we'll pretend it does for this demonstration). Time to get back to your messy home directory, right? Before doing that, press Ctrl-A Shift-M to monitor the current window for output. Now screen will notify you when there is activity in the FTP window. Bouncing between windows to check on your download's progress is no longer necessary. This also works in the inverse case; use Ctrl-A _ to monitor for silence (30 seconds by default). Monitoring for silence is useful for long compile jobs or other things that spew information.

You can continue to spawn new shells and do things in parallel on the remote machine. After you open a few windows, it becomes difficult to keep track of which window is where. This is where the windowlist comes in to play. Press Ctrl-A “, and you will be presented with a list of the current open windows. Navigate the list with the J and K keys. Pressing Enter on an entry will make it the current window. By default, the window name isn't all that descriptive. You can remedy this by setting the window name yourself with Ctrl-A Shift-A. You can set these titles automatically, much as you would set titles in an xterm, by sending Esc-K, then the title, then Esc-\. Most likely you can adapt a shell-specific recipe for setting the xterm titlebar to the screen window name using the mentioned escape sequences.

To finish up our basic run-through of windowing, let's close your existing windows. If you exit the shell that screen has spawned, the window is deleted automatically. You can delete a window manually with the kill command (default Ctrl-A K). When you exit all of the screen windows, screen exits. You also can tell screen to exit and kill all of your windows by issuing the quit command (Ctrl-A \).

Now that you're creating new windows and bouncing around between them, you can get many things going in parallel. You could potentially have some editors, an IRC client and a few other things all running in their own windows. But occasionally disaster strikes, and your network connection dies (those of you still playing along at home can kill your SSH client). It looks like it's time to pick up the pieces and relaunch all of your applications on the remote machine, right? Not with screen.

Each time you start up screen without arguments, it creates a new session. This spawns two processes: a terminal management process and a client process. The client process automatically is “attached” to the terminal management process. When you type, the characters you enter go to the client, which sends them to the terminal management process, which then sends them to your application.

When your network connection dies, the client catches the signal and detaches from the terminal management process. The terminal management process continues along managing your terminals as if nothing happened. When you log back in, you can list running sessions by issuing screen -ls at the prompt. It should show something similar to the following:

There are screens on:
        24319.pts-9.hostname (Detached)
1 Sockets in /var/run/screen/S-youruserid.

This shows that your session automatically detached when your connection dropped.

You can re-attach to the session in a few ways. You can give a session name explicitly with screen -r sessionname. You can tell it to re-attach if possible, otherwise start a new session by running screen -R. Or you can go the “do whatever is needed to get a screen session” route and run screen -D -RR. This last option will detach already-attached clients and attach to the first session listed.

When you run one of these commands, you should be right where you left off before your network connection went down. When you're re-attached, you can continue working as if nothing ever happened.

It is also possible to attach to a session multiple times. This is useful if you haven't closed your screen session from another machine, or if you simply want to display windows from the same session side by side. You can multi-attach by adding an -x in the command-line options to screen when attaching.

Finally, when the end of the day rolls around and it's time to go home, you can detach from your session using Ctrl-A D. When you return the next day, you can re-attach, and you will be back where you left off.

One of the key features listed in the beginning of the article was screen's searchable scrollback. This is a feature I could not live without. It's not immediately obvious to the new screen user, but screen's scrollback is accessed via the copy command. (You can enter copy mode with Ctrl-A [ or via the copy command.) Navigation works as expected with either the Arrow keys and Page Up/Down or the vi motion equivalents. Searching is accessed via either / and ? for vi-style search or Ctrl-S and Ctrl-R for incremental search. Case-insensitive search can be turned on with the screen command ignorecase yes. If you are using copy mode for scrollback only, it can be exited at any time with the Esc key.

To copy text, maneuver the cursor to the beginning of the desired text, and press the spacebar to mark it. Then position the cursor over the end of the text you'd like and press the spacebar again to mark it. When you mark the end, the text is copied into screen's internal copy buffer, and copy mode is exited. You can paste the text in your copy buffer into the active window with Ctrl-A ].

The final thing you should know about the copy and paste mode is the scrollback buffer is limited to 100 lines by default. This is, in my opinion, not enough. You can tweak this to a higher value (1,024 for example) by adding the command defscrollback 1024 to your .screenrc.

I have already mentioned that you can add a command to your .screenrc to change the behavior of screen. It's not immediately obvious, but you can put any screen command in a screenrc. This is very useful and can be used to spawn windows automatically with the screen command.

A typical application of this tidbit of knowledge is to launch a predefined set of windows at screen startup. Below is a sample screenrc that will do so:

# read in your normal screenrc
# before anything else
source $HOME/.screenrc
# now start opening windows
screen top
# it's possible to set the window title with
# the -t option
screen -t irc epic
# you can also specify the window number
# to launch in
screen -t mail 8 mutt
screen -t daemon 9 tail -f /var/log/daemon.log

If you save this to $HOME/.screenrc.multiwin you can tell screen to use it instead of your normal .screenrc by running screen -c $HOME/.screenrc.multiwin.

You also can launch more systems-oriented screen sessions from a startup script. A common application of a system screen session is a serial console server. Screen is well suited for this task because it has built-in support for serial terminals and logging. A commented example of a screenrc for this purpose is:

# This assumes that serialuser has proper
# permissions to access the serial ports and to
# write to the log files specified in the screenrc.
# turn logging on for all windows
deflog on
# tell screen to log to /var/log/serial.$WINDOW
logfile /var/log/serial.%n
# open windows on the serial ports
screen /dev/ttyS0 38400
screen /dev/ttyS1 19200

If you saved this file in /etc/screenrc.serial, you could launch it at startup with a script that runs:

su serialuser -c \
'screen -dmS serial -c /etc/screenrc.serial'

It is possible to set up a single system-wide screenrc that allows multiple users to connect to it. Screen supports multi-user mode with per-window ACLs that define what each user can and cannot do. Multi-user screen sessions, however, require that screen be setuid root. Because of this requirement, I am not going to include examples for multi-user screen sessions in an introductory article. If you would like to set up a multi-user screen session, read the screen docs, put on your “adding setuid root permissions to a complex piece of code” paranoia hat and be prepared to lock things down as tightly as possible.

As a third application, you could merge the two previous examples and launch system-wide interactive programs via screenrc. A good use of this would be launching mutella, a curses-based gnutella client, at startup. With screen, you can launch this program and connect to it on occasion to see the status, run queries, etc.

You can find further information on screen in the screen documentation. The documentation is provided in both man and info format. I prefer the info format when browsing and the man page when searching for specific things, but that's a personal preference.

There are also a few on-line resources for screen users. First is Sven Guckes' screen pages at www.math.fu-berlin.de/~guckes/screen. Second is the helpful screen mailing list at groups.yahoo.com/group/gnu-screen. The mailing list is the first place you should go with questions after you have exhausted the available documentation. You must be subscribed to post.