Be Productive: Use Screen
My development machine exists in “the cloud”, so to speak. At Famigo, Amazon EC2 powers both our development and production environments. I still connect to EC2 using good old-fashioned hardware, but the only thing I know about my development instance is that it gives me a shell prompt.
Growing up, my dad introduced me to Linux, but not in the usual client-server fashion. I frequently used Linux, sitting directly in front of the machine, connected with a keyboard. More often than not, I set up a GUI so I could see more than 80 columns and 24 rows.
By the time I got to high school, I was better acquainted with the client-server model. I routinely connected to servers to start or administrate long-running tasks. In particular, I ran a Counter-Strike server for me and my friends. It didn’t take me long to realize that I needed decouple the terminal from the commands running in it.
My first attempt was to push the server into the background. I don’t
remember the exact command, but it was something like
That didn’t work too well. It spammed the console with the server’s
output. After a bit of searching I found a tutorial explaining
how to run it in a “screen”. It was a revelation.
By “screen”, I mean GNU Screen. I use it all day, every day. It makes working from home a cinch. I can leave work without doing anything other than closing my terminal and pick it up at home without doing anything other than opening a new terminal. Screen is a powerful tool, but you don’t need to know much about it for it to be useful.
As soon as I SSH into my development box, the first thing I do is
screen -dR. That command detaches the screen from any other
terminals and connects it to mine. If a screen doesn’t exist, it
Now that I’m in the screen, I hit
C-a " to see all my windows.
The output typically looks like this:
Num Name Flags 0 server $ 1 bash $ 2 test $ 3 git $
As you can see, not a whole lot going on. I’m running a server in
screen 0. I can easily go to it (with
C-a 0) to catch Django’s
output. Screen 1 is where I do all of my actual work; it’s usually
running Vim. I run all of my unit tests in screen 2. This is
handy because I can flip back and forth (with
C-a C-a) between
the test output and the code that broke it. Finally, I handle all
my git commands in screen 3, which lets me commit frequently while
still keeping all my files open and tests running.
So there you have it. That’s how I use screen to be productive at work.