|
From: R.K. O. Ph.D. <rk...@ow...> - 2002-01-12 12:25:00
|
Hello Harlan:
Read through the INSTALL.RH7x document, because what it describes is
how to set up modules for all users on a system (in this case Linux/RedHat 7.x).
It also points out some of the pitfalls (especially with /bin/sh).
Essentially, I have my system rc scripts alias sh to bash, because then
you get the per-process sys rc scripts getting invoked to define the
necessary modules functions, etc.
Convert all your '#!/bin/sh' scripts to use '#!/bin/bash' (which should
cause no problems). And for your scripts you can have regular module loads:
if echo ${LOADEDMODULES:-none}| grep -q perl5 ; then
: # OK
else
echo "perl5 module is not loaded ... don't waste my time!"
echo "loading perl5 module myself!"
module load perl5
fi
I think something like this is safer, because if each script invokes
the modules/init scripts, then you have it rewriting the
$HOME/.modulesbeginenv and, I think, resetting the *MODULE* env.vars.
All you're really after is defining the aliases (or functions) for
whatever shell you're in.
R.K.
+------------------+---------------------+
| R.K.Owen,PhD | rk...@ow... |
| KooZ Software | Environment Modules |
| NERSC/LBNL | rk...@ne... |
+------------------+---------------------+
On Fri, 11 Jan 2002, Harlan Stenn wrote:
> Here's more.
>
> We're writing scripts that want to call "commands" that are defined
> by modulefiles.
>
> We noticed that sometimes these scripts worked, and sometimes they
> didn't.
>
> I have just discovered that these scripts fail when they are called
> by other scripts (as opposed from being invoked from the command
> line) and this seems to be due to the fact that:
>
> - we're writing the scripts ASSUMING that the modules stuff is available
> - - this has been true for us because we use shells that run startup (RC)
> scripts on each shell invocation
> - in performing some cleanup we are apparently making some changes that
> mean that sometimes we don't run the entire suite of RC scripts
> - this means that in some cases where scripts call scripts that the
> shell aliases created by the modules RC stuff are not being created
>
> I figure there are two ways to proceed:
>
> - be VERY careful when writing scripts to make sure we source in a
> suitable "modules init" function that also does our "loads"
> - make sure we have per-shell (for *all* useful shells) RC files
> that handle the modules init and our "loads"
>
> The first choice seems to be a bit better in that we'll only be doing the
> modules setup on those scripts where we need them. The downside of this
> method is that scripts will break until we find all of these cases.
>
> The second choice is less efficient (as there are going to be lots of
> times where we won't be using modules but we have to do the work
> anyway), but it has the benefit of putting the burden in a single place.
>
> Does this make sense?
>
> H
>
> -----Original Message-----
> From: Harlan Stenn
> Sent: Friday, January 11, 2002 7:05 PM
> To: Modules-Interest (E-mail)
> Subject: shell scripts that need "modules" stuff
>
>
> So what's the right way to write shell (for arbitrary versions of shell)
> script
> that include "commands" and things that are defined by the modules stuff?
>
> Does each script that needs to do this have to source in
> $MODULESHOME/init/$SHELL
> (or something similar)?
>
> H
>
|
