I have a confession: I kind of like reading about how people have their Unix work environments set up. In the spirit of sharing what I like, I'm going to write up some stuff about my own environment.

By now my personal Unix environment is highly evolved, which is to say that it is extremely customized (and somewhat littered with historical remnants). The customization rests on a whole pyramid of shell script tools and little programs so I am going to talk about them one by one, starting with the base of the pyramid and working up.

The job of my rxexec script is to run X programs remotely (hence, sort of, its extremely cryptical name). I started this habit back in the days before ssh, when you had underpowered workstations plus relatively powerful servers, and it made a real difference to run xterm remotely (putting essentially no load on the local workstation) instead of running a local xterm, rlogin, and perhaps a shell.

Since it predated ssh, the original version of rxexec used rsh to run a complicated set of magic commands on the remote machine. When ssh came out, a great deal of the magic was steadily replaced by more and more use of ssh features (as it became more and more pervasive around campus). Today, rxexec has only a few features over plain ssh -X <host> <command>:

• it forces the command to be executed by the Bourne shell, no matter what my remote shell is.

• it arranges to set $PATH on the remote end to include pretty much every place that X programs have ever lived, including local places, so that I don't have to care where today's system puts xterm.

• it has a mode where it sets up my entire environment (as if I had logged in) before running the command, so that I don't have to use xterm -ls or the like.

  (This requires a very specific setup for my account on the remote system.)

• it takes care to disassociate ssh from any controlling tty that it may have, because in my peculiar environment not doing so can cause things to go wrong.

I've deliberately chosen not to use 'ssh -f' in rxexec; I prefer to do any backgrounding outside rxexec, and this way I can use it in situations where I want to wait for the remote (X) program to complete.

Sidebar: what the rsh version of rxexec did

The basic incantation of the rsh based version was something like this:

echo "PATH=...; echo <magic-cookie> | xauth nmerge -; exec $command -display $display $@ <&- >&- 2>&- &" | rsh $host 'exec /bin/sh'

(There was a bunch of other code in rxexec that extracted the necessary Xauth magic cookie, mangled $DISPLAY, and so on. All of this became surplus when ssh became common, much to my relief.)

One reason for this complicated incantation was that I wanted to end up with no surplus processes lingering around on the remote machine (or for that matter, on my own workstation). The ideal outcome was to have only the remote X program itself still running; the rshd, the shell, and so on should all exit.

In the old days, this was drastically complicated by rshd's habit of gifting its children with random open file descriptors. If not closed, these would result in the rshd process not terminating until the X program did, much to my annoyance. (This is where the Bourne shell exec limitation could become very annoying.)