Home » from me to you

Peep into my toolbox 1: screen

5 Januar 2011 1,625 views 3 Comments

I’m a researcher in music information retrieval, and I will tell you about the software tools I use, hoping that you will be able to read about some you might not have heard of. None of the tools I use are perfect, and there are always other ways of doing things. So don’t get angry at me if you disagree, maybe you could even let me know, so that I can discover your better way of doing things! Also, this is not a tutorial.

After all that disclaiming, let’s get to today’s tool: screen. It is a terminal window management tool which comes with most (all?) Unix systems, including Linux and Mac OSX. This may seem an unlikely choice for the first tool I’m telling you about, but it has radically changed the way I run experiments. To me, it’s most useful when connecting to a remote server via ssh. Many research labs have big processing machines for researchers to execute number crunching tasks on, and screen makes this very much easier by creating an virtual “screen” within your terminal window. This virtual screen acts as if it were an actual screen connected to the remote server, so when you lose your connection to the remote server — nothing happens. The virtual screen will still be a virtual screen at the remote server, waiting for you to log back in and look at it. To see why this is useful consider the following scenarios:

  • Bad connection: you sit at home working on your university’s server using a Matlab interactive session because you can’t afford to have Matlab on your local computer. You’re trying out new stuff. Then the network fails (probably you use Virgin). Your current session is lost, and even if you’d saved everything, it’s a pain to restart Matlab, maybe set the path, re-calculate … well, you know. Had you been working in a virtual screen, then you’d only have had to ssh to the server again and do screen -r, and you were back exactly where you left off. Phew.
  • Extensive number crunching: this time you want to lose the connection because you fancy having a coffee at Starbucks and need to take your laptop (of course!). But you’ve just started a Python experiment on the remote machine, which will take another 10 hours to finish. Easy if you’re using screen. You just use the key combination Ctrl-a, then d to tell the virtual screen you don’t want to see it any more. And you’re done. Unplug. Next time you’ll find the screen waiting for you, and you can resume work where you’ve left off.

These are only two almost trivial examples, but they are the reason why screen is so useful to me. You can do much more elaborate stuff, for example open several windows in one virtual screen, or even several virtual screens. All in all: fabulous. To learn how to use it, refer to the manual page or simply the Wikipedia entry.

Edit: I found a very useful way of customising screen here. Essentially, by adding this line

caption always "%{= kw}%-w%{= BW}%n %t%{-}%+w %-= @%H - %LD %d %LM - %c"

to the “.screenrc” file (you might have to create the file first) in your home directory you can add a nice tab bar at the bottom of the screen window, showing you the names of all windows, as in the screenshot.
tab bar in screen

3 Comments »

  • Ben said:

    I love love love screen. I basically run all of my batch processing in screen instances. There’s another scenario I use it in: starting a process while physically at a machine, then checking up on it via an ssh remote connection some time later. This is similar situation to the second one you mention, just with two machines, one of which is actually running the screen instance. I tend to do this on a very regular basis since the building at Goldsmiths closes at 9pm, though I tend to work well past that time.

  • Matthias said:

    Now that you mention it, I do check back from a different machine sometimes. It gets kind of crazy if you log in from a smartphone, as I know Yves does :)

    I also use several windows to handily run several processes on different CPUs — though maybe that could be done more efficiently using background processing and logs … something I’m not yet very good at, but getting there.

  • Ben said:

    Well this isn’t a generic job manager, but I find it very useful for running lots of python processes, especially when they need to talk to each other: http://celeryproject.org/ , you might find it helpful, depending on how pythonic your existence is.

    right, back to screen love…