summary - finding commands in a multi-vendor universe

[allegra.att.com">jpl]

Responses have died down, so a summary is in order.  My original
questions were, in a multi-vendor universe:

1) How do you find the ``rsh'' command that invokes a remote (not
   a restricted) shell?
2) What do you put after
   PATH=
   in scripts that should run on all machines?

I got several thought-provoking replies, though fewer than I had
hoped.  I thought this would be a common problem in the SAGE
community.  The ``summary'' is mostly musings by me, inspired by
observations from others.  It is long.  Here's a short version.

A) The problem is neither simple nor solved, although Bob Arnold
   (rcaingres.com) sent me a LISA paper (LISA V, 30 Sep - 3 Oct 1991,
   San Diego) describing a system that works for him in a universe
   comprising more vendors than I ever hope to handle.

B) The original questions don't define the class of problems which
   are really at the heart of things.  The responses, and Bob's paper
   in particular, caused me to rethink what I was asking.  (That's
   the advantage of seeing all the replies, not just a summary.)
   The questions were provoked by the introduction of SGI machines
   into what had been a Sun world.  We have a large number of
   administrative scripts that keep things humming.  We'd like
   these scripts to work in the SGI world, too.  We administer
   both worlds.  There was no existing SGI community to worry about.
   Most scripts are /bin/sh scripts, but a few csh scripts must be
   ported as well.

C) Having a search path that starts with a directory under sysadmin
   control goes a long way towards solving our problem, as well as
   some related ones.  That directory can ``redirect'' references to
   ``rsh'', ``mail'', ``echo'' and such to the ``correct'' place.
   The ``big deal'' is that existing scripts need no modifications
   (beyond setting the search path).

Many people mentioned that in addition to ambiguity between rsh-as-
remote-shell and rsh-as-restricted-shell, there is the complementary
problem of the the remote shell being known by several different
names, for example, remsh.  The admin directory in the search path
solves this problem... rsh and remsh can be links to the same place.

Many noted that they used the uname command, or some homebrew version
thereof, to allow a command to identify its operating environment, and
behave differently in different environments.  We have done some of
this.  It matters a lot (to me at least) where the testing happens.
I don't want to see it in the scripts, because it would take a lot
of editing to put it there.  More to the point, I find it ugly and
confusing, like heavily #ifdef-ed C code, and spreading it into a
gazillion scripts is asking for trouble when changes must be made.

Some folks put ``function wrappers'' around ambiguous commands, and
let the shell do the vendor determination and command redirection.
While I prefer this to doctoring each script, I don't expect to head
in this direction.  I'd need a parallel set of functions for the
csh scripts, and I distrust the ability of functions to survive
when a script invokes an editor, then !'s back out.  I'd like the
mechanism to be the foundation for user scripts and logins, as well,
and users expect to be able to redefine ``mail'' by putting a
variant in a private directory at the start of their search path.
Functions don't honor search path semantics.

Here are a few ideas or observations about the problem in general.

1) Don't use full path names for the commands in your scripts.  I used
   to do this for scripts that were to be run by users, where I wanted
   them to be able to provide their own versions of certain commands
   (so I didn't want to set an absolute search path), but I wanted to
   be sure to get a few critical tools from the ``right place''.
   Bad idea.  Sophisticated users have no problem copying and modifying
   scripts to suit special needs.  Most naive users don't (deliberately)
   replace standard commands with their own versions.  Hotwiring the
   path names precludes the use of whole classes of porting aids
   (aliases, functions, search path rearrangements) that you'd like
   available when you find the commands are no longer where you expect
   them.  When I'm trying to preserve user flexibility now, I do
       : ${formatcmd=pr}
   so a sensible default is used, but can be overridden without
   modifying the script.

2) Actually replacing a command supplied by a vendor is risky business.
   Who knows what vendor-supplied script relies on what vendor-specific
   ``feature'' of some command.  I have enough scripts of my own to
   worry about without taking on those supplied by the vendors.

3) The simple expedient of setting
       PATH=`/etc/standard/path`
   buys a lot of flexibility in a lot of environments for a minimal cost.
       . /etc/standard/setup.sh
   buys more flexibility, but at a higher cost.

4) Use of the same name for incompatible commands is the root of
   much evil.  We, the SAGEs, can probably do ourselves a big favor
   by identifying the common collisions, and agreeing on unique names
   for the different commands.  It's much easy to bind an unused name
   to an existing command than to sort out which of several commands
   sharing the same name was really intended.

5) One of Bob Arnold's nightmares is that /etc/dist and /etc/saenv
   (two names embedded in his tools) will be appropriated by some
   vendor.  Something to contemplate is staking a claim on /etc/sage,
   control over which will reside with the SAGE powers.  I don't have
   the clout to get the attention of a vendor.  SAGE does.  All the
   vendors have to promise is to keep out.

About item 3), which is something I want to act on promptly.  I'm
inclined to adopt the simple PATH= solution over the more general .
solution (although sourcing a file is SO much more powerful than
altering a path, maybe I'll source a file that does nothing more,
initially, than change the path).  We get into religious issues, which
is why I held this for the end.  Beyond the obvious fact that I'd need
to provide a comparable /etc/standard/setup.csh for csh, I like the
``discipline'' of only tampering with the search path.  It relies only
on the search path mechanism, something that has been around for a very
long time, and is hard for vendors to get wrong.  This is NOT true of
things like aliases and/or shell functions.  So the odds of the
solution introducing subtle new problems are reasonably small.

Although symlinks in the initial search path directory can take care of
many problems I have encountered (rsh, echo and mail, for example),
the same mechanism can take on more complicated problems.  For example,
the SGI ``mt'' command wants an explicit device argument supplied using
a ``-t'' flag, whereas Sun used to prefer ``-f''.  A simple shell script
in the special-case directory could convert to the appropriate flags,
and even change Sun's ``mt asf N'' command into ``mt rew; mt fsf N'' on
the SGIs, where ``asf'' is not supported.  I don't feel nearly as
comfortable about this class of solutions as I did about simple symlinks,
but the point is, it is available, and spares the need to change scripts
(once you identify that the problem exists).

The ``correct'' solution for the long term almost certainly involves
standards.  My universes seem to be converging on SVR4 as a standard,
so if I MUST go about recoding scripts, I'll recode to some well-
established standard and, if I must, I'll supply a perl interface
to make things behave correctly until the vendors support the
standard.  This at least reduces the problem of dealing with N
vendors to order(N), rather than an order(N**2) problem of getting
scripts from vendor I to run on vendor J.  Maybe SAGE should look
into tackling some of these interface mappings?

Thanks to insights from
Steve Blair		sblairupurbmw.dell.com
DaviD W. Sanderson	dwsssec.wisc.edu
Wayne Trzyna		trzynaCS.ColoState.EDU
Bob Arnold		rcaingres.com
Sherwood		sherwoodspace.ualberta.ca
David H. Wolfskill	sun!dhw68k.cts.com!david
Daniel Rich		drichsandman.lerc.nasa.gov
johno			jcobbn.com