You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

This short document is about a wonderful tool called 'screen'. The next few sections will explain what screen is and how it can be useful to you. If you already know what screen is, and what ctrl-a does, you'll probably want to skip ahead to the 'Useful tips' section. If you are not a big command line user, you might want to stop right here and go read something else ;) Screen is not very useful in GUI situations.

What screen is

Screen is a program that emulates multiple console 'windows'. Through a few special keystrokes, you can create new windows and switch to them at will. If you're familiar with using alt-f1 through alt-f6 to switch terminals, screen is exactly like that except that it works remotely too.

What screen is good for

Let me provide a couple of common scenarios. You are connected via SSH, and you start a process that's going to take a while. The sort of process that takes around 6 hours to complete, and prints a lot of progress or status output to the screen. Around halfway through, you find you want to do something else while it works, or perhaps you're just sick of this status output being sent across the network. You can background the process, but the status output constantly interrupts your second task, and makes it impossible to even see what you've just typed. You could stop and restart the process with the output redirected, but that would lose the work already done. If you haven't guessed already, this is one problem screen can solve.
Another problem you might have is using SSH to connect to a machine over a dodgy link. Perhaps there is a modem and a noisy line involved, or perhaps your ISP regularly disconnects you to stop you from running a reliable public server from home (grrr). Again, screen can save the day.

Installing screen

Uh oh! You've caught me - I am far too lazy to write up instructions for all the different distros. I'm even too lazy to write up instructions for compiling from source. The best way to get screen is to grab the appropriate package for your distro and install it - I can almost guarantee it already exists. If you're using SSH to connect to remote machines, I think it's a fair bet you know how to install packages for a given system. If you'd like to compile screen from source, you can find it on the GNU homepage here: http://www.gnu.org/software/screen/

Using screen

There are a few ways to start screen. The simplest is just to type 'screen' at the prompt. Once you have screen running, the most important thing to remember is "ctrl-a". This is the key sequence that grabs screen's attention, to signal a command. There are a few commands, but the two most useful (especially for your first foray into screen) are "create" (c) and "next" (n). 'Create' is to create a new window.
Try it out. First get something on the display - ls some files or something - then press ctrl-a, and then c. You should see the display cleared, and a fresh prompt. 'Next' cycles through your available sessions - try ctrl-a, n - you will switch back to the window with the files you just listed. If you need to send a literal ctrl-a without being intercepted by screen, you can use ctrl-a, a. If you haven't guessed already, there is also 'p' for 'Previous' to cycle backwards.
If you need to send a literal ctrl-a to your system, use ctrl-a,a.
There are a lot of other quick commands, though these are the most useful and the easiest to remember. There is one more very useful one - ctrl-a,d will 'detach' screen. This returns you to your original terminal, effectively closing screen but without killing or even pausing all your shells and processes. Your screen session can be 'resumed' later with "screen -r". This is especially handy for those long jobs that keep printing status output - the output can be stored in a session until you are ready to view it.

Customizing screen
In the next few paragraphs, I will mention your screenrc file. If you want to change something for every user on your system, you will want to change /etc/screenrc. If you want to change something just for one user, change their $HOME/.screenrc file instead.

When you first run screen, you will probably get an annoying message about how it is free software and bla, bla, bla. Chances are high you will know this already, and even higher that you won't care to see this message every time you use the program. Fortunately, you can disable the message by adding:

Code:

startup_message off

to your screenrc file.

Another thing that will probably start to annoy you (and cause epileptic fits in some) is the default 'visual bell' setup. Any time a bell would normally sound (say, you hit tab for tab completion, and there are multiple matching files), the entire screen will flash. You can disable this with:

Code:

vbell off

in your preferred screenrc file.

If you don't like ctrl-a (your terminal program has a problem with it for some reason, or perhaps you use a piece of software that requires use of ctrl-a a lot), you can change the command key temporarily via the command line, or more permanently via one of your screenrc files. For example, to change to ctrl-g, you could use the command line:

Code:

screen -e^Gg

The ^G sets the control character, and the second g is the key to use to send the literal control character instead. To put an entry for this in the screenrc, use:

Code:

escape ^Gg

As with control keys, there are many more customization options than presented here. These are just the ones you are most likely to need immediately.

Useful tips

If you're like me, a program you have to remember to start before it becomes useful is not much good. Remembering you should have run screen two hours after starting your lengthy process is about as helpful as Clippy. Fortunately, there are a few ways to avoid this.

If you decide you like screen so much you want it running all the time, you can actually set it as your shell in /etc/passwd. This turns out to be less useful than it sounds, as each new login will attach to the original session, and logging out of one will log you out of all of them! A better way to force this setup is to add

Code:

exec screen

to the appropriate startup file for your shell (~/.bash_profile for example). You can then use

Code:

screen -ls

to view active sessions, and

Code:

screen -r <name>

to attach to one. If the session you want is still attached to a terminal, use

Code:

screen -d -r <name>

instead. In this way, you can connect via SSH and check on the progress of a task you were running on tty1.

For myself, I prefer to use screen only when logging in via SSH. This way, my SSH session is automatically resumed if I am disconnected for any reason. I do this by adding these lines to my ~/.bashrc:

Code:

if [ "$SSH_CONNECTION" ]; then
if [ -z "$STY" ]; then
# Screen is not currently running, but we are in SSH, so start a session
exec screen -d -R
fi
fi

The check for STY stops bash from creating a new screen process every time I create a new screen window, and the -d -R parameters tell screen to reattach an existing session, or create a new one if necessary.

Summary

Screen can be a powerful and useful tool if you do a lot of command line work, especially if you need to check on long-running processes from time to time from different locations. This document barely scratches the surface of what screen can do. There are options to launch processes automatically as soon as screen starts, or to allow multiple users to share sessions with each other. If you want to learn more, the screen man page is very complete and well written. My hat is off to the authors of this fine piece of software.

I use ssh to my linux boxes constantly, even though I also use freenx occaisionally also.

I feel like a goon because I never knew about screen and was always backgrounding processes...

Screen is a great tool!
Thanks for the write up.

by dsplabs on Thu, 2007-12-20 00:45

Is there a way (using f.e. an entry in .screenrc file, or some other way) to log an entire screen session to file?

by theNbomr on Sun, 2010-06-13 10:16

Screen has another potentially indispensable feature that is too seldom documented: multiuser mode. When appropriately configured, you can start up screen sessions that can be attached to by other users. Of course, there are access controls that allow you to configure who can attach and what rights they have.
In my work, this is heavily used to run processes that are intended to run perpetually, and that also have an interactive aspect. Anyone in my work group needs to be able to monitor these processes, and there are often numerous such processes running concurrently. We even have a GUI utility written in Perl/Tk that allows users to easily find, select, and open existing sessions or start new screen sessions.
I can envision other purposes, such as making a terminal session visible to all members of a 'classroom' (where the class could consist of remotely logged-in students).
Your example of 'backgrounding' long-running processes is a good one. Sometimes I will start up such a process, like a kernel build, at work, and then go home for the day. At home, I can check in by logging in with SSH, and re-attach to the screen session to monitor its progress.