The advantages of using screen
There's a reason I posted a screen cheat sheet
on my home page, and it's because I use screen so much that I actually needed one for myself.
screen is a tool which isn't suited for all audiences. Its
home page states that it is a "window manager" which multiplexes terminals. That basically means it's a
terminal manager, and all graphical environments have terminal managers, right? So why do we need another
one which has complicated keybindings and doesn't let us use the mouse?
Well, each one might have their reasons, but for scientists there is one very clear advantage: working on the same shells from different terminals. What? Let's look at an example:
You usually have a computer from which you work every day. From that computer you ssh into
different servers, clusters, etc. So, in the end, most of us have a monitor full of xterms—or
any other terminal emulator. That's fine. But then we arrive home and want to check if that job we launched
has crashed, because we need the results tomorrow morning. So what do we do? We ssh into our
machine, or the server, open another session (that's the key here) and run some commands.
The problem is, you already had your sessions configured, maybe even set some environment variables,
had the history full of commands and the terminal buffer with some output, and now you can't recover that.
How about if you could restore the same sessions and windows we had at our work computer without
the need to open a VNC or any other graphical screen-sharing tools? That's what screen does.
To put it plainly, screen is a daemon that handles terminal connections, which means that you
can always request the same session that you had open before. Obviously it can't manage sessions unless you
open them via screen, so it's a good idea to always run your terminals through it, just in case
you might need to access them afterwards.
Besides ubiquitous access to your sessions, screen also provides other interesting features
that make it useful even if you don't need terminal multiplexing. The first is notifications for
terminals which are in background, for example, a visual message appears in your screen if there is a new
output in a hidden window. This is very appropriate to avoid constantly checking minimized windows.
It also provides window managing, i.e. many terminals in a single window, and quick switching. Finally, even on today's GUI world, sometimes you need to copy&paste without a mouse, backwards buffer management, perform text "screenshots", etc.
I'll end up with a quick tutorial by an example that actually happened yesterday.
carlesfe@work:~$ screen[screen opens, and gives me a shell]carlesfe@work:~$ ssh server.comcarlesfe@server:~$ work on some commands... run scripts...carlesfe@server:~$ launch_a_job.sh[output is being generated]
Then I left work and went home. Notice that the output is still being generated, but only in the
window that I had opened at work. Usually there are some other ways to check if the job is still running,
but what if it crashes? At home I wouldn't normally be able to recover the error message that was printed
on the screen. But with screen session management, I can do this:
carlesfe@home:~$ ssh workcarlesfe@work:~$ screen -x
And voilà! I can see the exact same window with the same session I had at work. Now I can monitor what's happening, relaunch the command easily if it crashed, and see any error messages that were output on the screen.
I started by saying that screen isn't a very user-friendly tool, but if you feel comfortable
with many of the Unix tools out there, you'll get used to it very quickly. Check out
this tutorial for a beginner's
introduction and give it a try for some days. Once you get used to the basic C-a keystrokes
and terminal management, you'll wonder why didn't you discover it years ago.
Tags: unix