About the hang-on-exit bug: this is the TODO item which shows up when you
run "ssh server 'sleep 20 & exit'".  Feel free to add the text directly to
TODO (I didn't, but only because it's a lot of detail that might not belong).

* The shell starts up, and starts its own session.  As a side-effect, it
  gets its own process group.
* The child forks off sleep, and because it's in the background, puts it
  into its own process group.  The sleep command inherits a copy of the
  shell's descriptor for the tty as its stdout.
* The shell exits, but doesn't SIGHUP all of its child PIDs like it probably
  should.
* The sshd server attempts to read from the master side of the pty, and
  while there are still process with the pty open, no EOF is produced.
* The sleep command exits, closes its descriptor, sshd detects the EOF, and
  the connection gets closed.

Attempts at fixing this in sshd, and why they don't work:
* SIGHUP the sshd's process group.
  - The shell is in its own process group.
* Track process group IDs of all children before we reap them (via an extra
  field in Session structures which holds the pgid for each child pid), and
  SIGHUP the pgid when we reap.
  - Background commands are in yet another process group.
* Close the connection when the child dies.
  - Background commands may need to write data to the connection.  Also
    prematurely truncates output from some commands (scp server, the
    famous "dd if=/dev/zero bs=1000 count=100" case).

Known-good workarounds:
* bash: shopt huponexit on
* tcsh: none
* zsh: setopt HUP (usually the default setting)
  (taken from email from Jason Stone to openssh-unix-dev, 5 May 2001)
* pdksh: ?

This appears to affect rsh as well: it behaves the same with 'sleep 20 & exit'.
