Hello All,
As discussed here in August [1], the module command may sometimes get
broken by current environment when it contains a LD_LIBRARY_PATH pointing
to an incompatible libtcl.so. Tcl interpreter running the modulecmd.tcl
tool will in this case not be able to perform correctly and raise error.
To protect the module command run-time environment from side effect coming
from the current environment definition a quarantine mechanism is
introduced. This mechanism, sets within module function definition and
shell initialization script, modifies the modulecmd.tcl run-time
environment to sanitize it.
The mechanism is piloted by environment variables. First of all
MODULES_RUN_QUARANTINE, a space-separated list of environment variable
names. Every variable found in MODULES_RUN_QUARANTINE will be set in
quarantine during the modulecmd.tcl run-time. Their value will be set empty
or set to the value of the corresponding MODULES_RUNENV_<VAR> environment
variable if defined.
The initial value these variables have will be passed to modulecmd.tcl via
the '<VAR>_modquar' variable. Then once modulecmd.tcl is started it
restores <VAR> to the content found in <VAR>_modquar (its original value).
If you have Tcl installed in standard system paths, by just setting
MODULES_RUN_QUARANTINE=LD_LIBRARY_PATH you will protect module from being
disturbed by other Tcl installation enabled in LD_LIBRARY_PATH. It will
stick to the regular Tcl installation.
MODULES_RUN_QUARANTINE and MODULES_RUNENV_<VAR> environment variables can
be defined at build time by using the following configure option:
--with-quarantine-vars='VARNAME[=VALUE] ...'
Quarantine mechanism is available for all supported shells exception made
for csh/tcsh. On this shell family, module is defined as a shell alias
which does not cope with foreach loop and nested if conditionals.
All of this is available in the master branch of the git repository and
will be part of the next feature release (4.1).
Cheers,
Xavier
[1] https://sourceforge.net/p/modules/mailman/message/36001597/
|