[22] in Locker Maintainers
Re: shared "binary" directory
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Jan 23 15:58:37 1998
To: Jeremy C Daniel <jdaniel@MIT.EDU>
Cc: locker-maintainers@MIT.EDU
In-Reply-To: Your message of "Thu, 22 Jan 1998 23:22:54 EST."
<199801230422.XAA18198@x15-cruise-basselope.MIT.EDU>
Date: Fri, 23 Jan 1998 15:58:25 EST
From: Greg Hudson <ghudson@MIT.EDU>
I don't think we'll be using a central scripts directory any time
soon. Some reasons why not:
* Even with ATHENA_SYS_PATH, add will only put one arch
directory in your path (the first one it finds).
* An objection raised by Craig in athena_ws is that a user
looking through a locker would have to look in several
places to find the binaries they can run, instead of just
`athdir /mit/locker` or /mit/locker/bin.
* Most scripts installed in lockers are actually wrappers
around binaries. Such scripts are not really
architecture-independent at all, since there is a step of
"find the binary for this architecture and run it," and
which architecture's binary is used should really be
determined by the path used to reference the script. (This
really implies that there should be a different script for
each architecture, but most locker maintainers refuse to
live with this much maintenance overhead to address such a
picky detail.)
There are cases where a central scripts directory makes sense, such as
tcl scripts like exmh. I think they're a very marginal minority right
now. If Java goes somewhere and we start seeing a preponderance of
architecture-independent executables in lockers, we'll need to
reconsider the locker layout, but that day hasn't come yet.
One further note. Nathan wrote:
> I often run machines of random platforms which no locker maintainer
> will ever support, and I would like to be able to run those scripts
> without manually grovelling around to find out where the scripts are
> in that particular locker.
It's worth noting that a central scripts directory would cement the
practice I alluded to above of using a single script as a wrapper for
multiple binaries, a practice which frequently gets in the way of
using binary emulation.
