Modifying the stk script.

From: Harvey J. Stein <hjstein_at_MATH.HUJI.AC.IL>
Date: Thu, 24 Aug 1995 18:13:04 +0300

I agree that the current script is sub-optimal. I'm running Linux on
a 486-dx266, and see a noticable difference between invoking the
script and invoking the binary directly. It seems absurd to exec 5
extra processes every time someone runs stk. This is the stk script
itself, + the FOUR necessary for figuring out what directory the
binary is in. If you don't believe me, count:

   machine=`uname -s`-`uname -r | cut -d. -f1,2`-`uname -m`

In fact, if the shell invokes the shell to handle each of the
backquotes, it'll be more like 8 execs!

The first thing I do after installing a new version of STk is to
change the stk script to:

   export STK_LIBRARY=/usr/local/lib/stk/2.1.7
   exec $STK_LIBRARY/$machine/stk-bin -name stk $*

I also agree that if you have a multiple hardware net, then you must
have already solved the problem of all your other binaries, so
there's no need for the stk script to solve it for you.

I'd rather see the actual binary get installed in /usr/local/bin
(overridable at config time by --prefix=<alternative directory>).
Also, maybe two STK environment variables, one for where to look for
the machine dependent library files, and where to look for the machine
independent ones. I'd think these should be compiled in (defaulting
to standard places, but overridable with config switches) and
overridable at runtime by the environment variables. It might even be
good to have 3 environment variables. One for the machine dependent
files, one for the version dependent files, and one for the
independent files.

One could argue that the machine dependent files are inherently
version dependent, so one could require them to be in subdirectories
of the version directories, and thus get away with two environment
variables, but it'd be more flexable to allow people to shoot
themselves in the foot with 3 variables.

Dr. Harvey J. Stein
Berger Financial Research
Received on Thu Aug 24 1995 - 17:13:54 CEST

This archive was generated by hypermail 2.3.0 : Mon Jul 21 2014 - 19:38:59 CEST