Tuesday, September 22, 2009

Pair Programming with gnu screen

Good ole' screen, nothing beats screen
-- bart simpson (almost)

Setting up a screen session for sharing

  1. screen needs to be setuid root for multiuser sessions to work
  2. set the multiuser flag to on
  3. use acladd or aclchg to add acl rights for other users. This must be done after enabling multiuser.

make screen setuid:
ls -l $(which screen)
sudo chmod +s $(which screen)

Note in zsh this could be simplified by using = to replace the $(which ) block.
ls -l =screen;
sudo chmod +s =screen

Update: On recent ubuntu installations (9.04 and newer), /usr/bin/screen is a wrapper around /usr/bin/screen.real. /usr/bin/screen.real is the file that needs to be made setuid.

sudo chmod +s /usr/bin/screen.real

Note: I'll use "^A" to represent the screen key.

^A:multiuser on
^A:acladd usertwo
Now usertwo can see the screen session of userone with the following command (The trailing slash is important!)
  screen -ls userone/

And connect with either of:

  • screen -x userone/
  • screen -x userone/name-of-session
In the latter case, name-of-session is used as a search string within the available named screen sessions.

If you used acladd, then usertwo comes in with full capabilities -- write and execute. It is possible to restrict users to write bit (allows sending chars to the screen, assuming no one else has write-lock) and execute bit ( allows screen commands to be run ). These commands can be granted on a per-screen and per-user basis.

Check out more on the screen man page.

Now, you and your remote pair can get back to work. One of you coding, one of you watching. Both of you creating.

Hints:


  • try and get this set up and running while userone and usertwo are both local so it is easier to debug.
  • you'll need to own your own pty. This is not normally a problem, unless you are using su or sudo to change users, which you may want to do while testing.
  • don't forget to set multiuser to on *before* trying to set the acl commands, I think that was important.
  • Use an out-of-band method for communicating. I like a VOIP connection or even a ytalk or irc back channel. ( I'm still waiting for a jabber based tool that will do all of this for me, all while integrating into vim. )
  • give your screen session a useful name with the -S flag, like screen -S shared or screen -S bug_1234
  • I have vim on one screen, open with my perl module and my .t test (vim -o foo.pm t/foo.t), and a second screen primed for running the test file. If test output is short, I just run it in the vim session with :make , but for long, slow, verbose tests, I run them in a second window. This lets my screen partner run tests at his/her leisure while I'm typing code.
  • set your shell to auto-update the screen title for a given screen when a command is run.
  • use double-quote ^A" to get a named list of screen windows, choose the window to switch to by number, j/k or arrows. These two make it easier to follow what is going on.

1 comment:

Ian Douglas said...

This worked well for Andrew and I, especially in remote pair programming along with Skype for vocal/visual communication.