== A building block of my environment: _rxexec_

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 TwoEnvironmentsApproach]] 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 ../unix/BourneExecLimitation]] could become very
annoying.)