I started using Screen on a daily basis, and quickly desired an ssh-agent tied to a long-lived screen session.

The obvious solution (running "ssh-agent screen") doesn't work - as soon as you log out, screen drops into the background and you lose the agent.

People have solved this problem in various ways - a quick search shows some of them. I didn't like them. They all rely on scripts external to screen for running the agent and maintaining its environment variables.

I spent a little time last night on a solution. It's completely contained in your .screenrc, and produces an ssh-agent tied to screen's life cycle.

It's just two lines:

setenv SSH_AUTH_SOCK $HOME/.screen-ssh-agent

screen 10 ssh-agent -a $SSH_AUTH_SOCK $SHELL

This creates a screen (number 10) that holds your ssh agent. If you don't like 10, you can start the agent on any screen. Things still work properly. The agent will be available to all the screens in that session. It also persists if you close the screen it was started on.

Make sure you run the setenv line early enough in your .screenrc that it will take effect before you open new screens.

The only problem I have with this setup is that all my screen sessions share the same agent - the one listening on $HOME/.screen-ssh-agent. I'd like to make that one agent per screen session, using something like $HOME/.screen-ssh-agent.$$. Unfortunately $$ is empty from within .screenrc - I can't find a real environment variable that uniquely identifies the current process.

Sorry for the digression, now back to your regularly scheduled (Semiannual?) Hula news.

If you are offended by discussion about Emacs, please stop reading now.

Over the last few years, Dan Mills and I have been improving an Emacs configuration style we both enjoy using. There has recently been some interest in this setup internally, so I thought I'd pull some notes together and send it out into the world.

There were two original goals for this design:

1. A good, clean configuration - none of the mess that usually clutters .emacs files.
2. Easy deployment of new elisp packages.

I welcome you to continue reading.

First, all the elisp files I "own", either packages I've downloaded or things I've written myself, should exist under one tree. This eases maintenance, and allows me to keep everything in Subversion.

Second, all the relevant directories in that tree should be automatically added to the Emacs load-path, so I don't ever have to add anything manually when I want to try out something new.

Third, configuration files should be loaded automatically - I want to be able to drop settings in and not have to edit a file to get them to load.

Here is the result:

• All directories under ~/elisp that contain elisp files are added to my load path.
• All *-settings.el files under ~/elisp/settings are loaded automatically on start.
• Customized variables (M-x customize, that is) are saved in ~/elisp/custom.el.

Whenever I download something new and nifty, I put it in ~/elisp/packages. If it's a single file, I'll put it there directly. If it comes as several files (or even a deep tree), I'll put it in its own subdirectory. I add a settings file that loads that package, and off I go.

These settings files are often extremely short - all I want to do there is set the configuration variables I need to use the package.

I keep my .emacs file itself as simple as possible - it's not in the version controlled tree, and I tend to forget changes when I make them. At the moment, it has one line - hopefully it's simple enough for me to remember if I lose it:

(load-file "~/elisp/init.el")

A sample elisp tree containing that init.el file can be found here. There's a fair amount of documentation in the comments of init.el.