Skip to content

Remote pair programming with GNU Screen

I like pair programming. So much, in fact, that I want to do it even if I can’t look over the other person’s shoulder due to some geographical offset. Since I’m a real command-line freak, I can get what I want easily by using GNU Screen.

GNU Screen rehash

If you don’t know GNU screen yet and you ever find yourself using the command-line for an extended period of time, learn it. Now. I’ll name just a few advantages:

  1. You can manage multiple “windows” conveniently even if you don’t have a tabbed terminal emulator, or even when you’re not within a graphic environment such as X.
  2. You can “detach” and “reattach” your Screen sessions and continue exactly where you left. This is very useful if you do your work on a remote server, through SSH, for example. Never by stumped by instable connections again!
  3. But, the feature which is most useful for pair programming is the ability to attach to the same session from multiple terminals.

Starting GNU Screen is very easy. Just type screen at your shell prompt (or screen -S SESSION_NAME if you want your session to have an easy-to-remember name).

Press CTRL+A followed by d to detach. Exit your terminal. Start a new terminal, type screen -r and be amazed that you have your session back. screen -r can take as an argument the name or PID of the screen, which is useful if you have more than one screen running. To get a list of current screen sessions, type screen -ls.

Inviting your observer

The first thing you have to do is to add the following command to your .screenrc file:

multiuser on

If you don’t want to enable multiuser by default, you can also choose to type the command from within Screen each time that you need it. This is done by pressing Ctrl+A, followed by : and the command.

Myself, I prefer to have the command in my .screenrc. You need to admit users explicitly anyway. Admitting full access to a user is done by typing the :acladd USERNAME command (after pressing Ctrl+A). Then the given user can join this session by starting screen with screen -x SESSION_OWNER/ where SESSION_OWNER is the driver.

Get out of my driver’s seat! (Dealing with annoying observers)

The :acladd USERNAME command will give the observer full read-write access. Maybe, if you have to deal with an observer who insists on taking the driver seat, you want to limit his or her access to read-only. This can be done just as easily: press Ctrl+A; then type :aclchg USERNAME -w "#".

Make your terminals match

Using a shared screen, it can be kind of annoying if your terminal sizes don’t match. As an observer, I fix this by asking the driver to tell me the values of the $ROWS and $COLS environment variables. If then, for example $COLS=110 and $ROWS=40, I start my xterm with this in mind: xterm -geometry 110x40

Have fun with Screen!

I’ve only touched upon some of the things you can do with screen. The manual page contains much more information—perhaps a bit too much even. 😕

One of the things I also like to do with a shared screen session is remote system administration. If I want to perform delicate tasks as root, I find it kind of comforting if someone can stop me in time, before I do anything stupid. Besides, if you’re both root, you don’t even have to set permissions. 🙂 So, it’s easy to.


    5 Comments ( Add comment / trackback )

    1. On Oct 29, 2008 at 08:05

      […] BigSmoke » Remote pair programming with GNU Screen (tags: remote collaboration ssh pairprogramming screen) […]

    2. On Nov 28, 2008 at 00:15

      […] be using GNU Screen instead, which has too many advantages to name here. It even allows you to do Remote pair programming over […]

    3. On February 6, 2010 at 19:26

      Thank You!! 🙂 that’s really great!

    4. On Sep 23, 2012 at 02:34

      […] using GNU Screen instead, which has too many advantages to name here. It even allows you to do Remote pair programming over […]

    5. On Dec 14, 2012 at 05:42

      […] using GNU Screen instead, which has too many advantages to name here. It even allows you to do Remote pair programming over […]