A building block of my environment:
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
ssh, when you had underpowered workstations plus relatively
powerful servers, and it made a real difference to run
(putting essentially no load on the local workstation) instead of
running a local
rlogin, and perhaps a shell.
Since it predated
ssh, the original version of
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
$PATHon 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
- 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 -lsor the like.
(This requires a very specific setup for my account on the remote system.)
- it takes care to disassociate
sshfrom 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
The basic incantation of the
rsh based version was something like
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
Comments on this page:Written on 02 March 2010.