Add --with-quarantine-vars configure option to define quarantine
mechanism configuration at build time.
Value passed to the configure option will be used by Makefile to
initialize in the various initialization scripts the
MODULES_RUN_QUARANTINE variable and eventual MODULES_RUNENV_<VAR>.
Make use of autoinit module command to initialize module command and its
initial surrounding environment (default value for MODULESHOME,
MODULEPATH, LOADEDMODULES and parse of init/.modulespath).
Then if compatibility version is currently activated redefined the
module command to point to the compat binary. But the compat version
will benefit from the surrounding environment initialization made by
autoinit.
With this change, activated compatibility version will also get its
environment initialized by the init/modulerc file whereas before this
change only the main version was affected by this setup file.
Change from previous behavior where redirection were set if shell was
interactive. With this change, a 'sh script' command launched from a
terminal session will setup module stderr redirection whereas previously
it was not the case as script was not ran in interactive mode.
Shell interactive mode is useful to know that interaction will occur on
stdin (interesting for completion setup). Knowing session is attached to
a terminal seems to be the good pivot to adapt stdout or stderr
functioning (help to determine if PAGER mode can be enabled or not on
'git')
Introduce MODULE_USE_COMPAT_VERSION environment variable to control the
activation of the compatibility version rather main version in case of
--enable-compat-version installation.
The initialization script of the shells supporting compatibility version
are adapted to define the 'module' command based on the modulecmd-compat
binary if MODULE_USE_COMPAT_VERSION is set to 1. Elsewhere module is
based on modulecmd.tcl.
'switchml' function of alias is reintroduced to switch between main and
compatibility version based on the state of the
MODULE_USE_COMPAT_VERSION environment variable.
Acknowledgment: this development has been made and funded within the
framework of the PRACE Fifth Implementation Phase (PRACE-5IP) project
(http://www.prace-ri.eu/). PRACE-5IP receives funding from the EU's
Horizon 2020 research and innovation programme (2014-2020) under grant
agreement no. 730913.
If MODULEPATH or LOADEDMODULES is already set, do not source the
modulerc configuration file in init scripts.
As a consequence, if .modulespath sets a module path, then modulerc will
be ignored which clarifies how default configuration is loaded: if both
.modulespath and modulerc are defined, .modulespath takes precedence
over modulerc.
So if .modulespath sets a module path, all loaded modules defined in the
modulerc file will be ignored.
Introduce 'switchml' tool, a shell function (or alias for csh or tcsh
shells) that swap currently enabled Modules version (C or Tcl) by the
other version (C or Tcl).
In case a swapped version was defining specific PATH or MANPATH entries,
these specific entries are removed when switching to the other version
to avoid still relying on the binaries and man pages of the swapped-out
version.
Add the possibility to set PATH and MANPATH in shell init scripts
(sh-like, csh-like and fish scripts) if specific option are enabled in
makefile (enabled by default). With this, bin directory and man
directory of the modules-tcl installation are prepended to the MANPATH
and PATH environment variables.
Prepending is required for PATH as manpath utility in its default Linux
setup will automatically set MANPATH from PATH change, so if we want
MANPATH to be prepended, PATH has to be prepended.
Introduce an 'install' target in makefiles to provide an installation
process for modules-tcl.
Defines installation paths with Makefile variables in order to avoid
having a ./configure step. Install paths are set during the 'make' step
by passing 'prefix', 'libexecdir', 'mandir', etc arguments to the make
command. If no path definitions are passed to the 'make' command,
installation will be made in '/usr/local/modules-tcl' by default.
Installation paths provided (or set from the default value found in
Makefile) are saved at the 'make' step in a .makeinstallpath file. Then
at the 'make install' step, this .makeinstallpath file is read and make
knows where to install modules-tcl.
These paths definitions are also used to translate *.in init script to
their installed version.
modulecmd.tcl script is by default set to be installed in the libexec
directory to follow FHS specification (as this script is an executable
but not directly accessed by users).
Adapt shell init scripts (sh-like, csh-like and fish) to get module
defined in sh-like sub-shells. The method to define the module function
in interactive or non-interactive sh-like sub-shells vary according to
the shell flavor.
The below table is an attempt to summarize the method to use to get
'module' function defined in sub-shell depending of the SH-shell kind
and if the sub-shell is in interactive mode or not.
+-----+----------+-----------+-------+
| ENV | BASH_ENV | export -f | FPATH |
+-------------+-------------------+-----+----------+-----------+-------+
| |inter sub-shell | | | X | |
|BASH +-------------------+-----+----------+-----------+-------+
| |non-inter sub-shell| | X | X | |
+-------------+-------------------+-----+----------+-----------+-------+
| |inter sub-shell | X | | X | |
|SH +-------------------+-----+----------+-----------+-------+
|(BASH-compat)|non-inter sub-shell| | | X | |
+-------------+-------------------+-----+----------+-----------+-------+
| |inter sub-shell | X | | | X(*)|
|SH +-------------------+-----+----------+-----------+-------+
|(ZSH-compat) |non-inter sub-shell| X | | | X(*)|
+-------------+-------------------+-----+----------+-----------+-------+
| |inter sub-shell | X | | | X |
|KSH +-------------------+-----+----------+-----------+-------+
| |non-inter sub-shell| | | | X |
+-------------+-------------------+-----+----------+-----------+-------+
| |inter sub-shell | X | | | X(*)|
|KSH +-------------------+-----+----------+-----------+-------+
|(ZSH-compat) |non-inter sub-shell| X | | | X(*)|
+-------------+-------------------+-----+----------+-----------+-------+
| |inter sub-shell | | | | X(*)|
|ZSH +-------------------+-----+----------+-----------+-------+
| |non-inter sub-shell| | | | X(*)|
+-------------+-------------------+-----+----------+-----------+-------+
(*) autoload required
Shell init scripts have been adapted to implement these different method
to cover most of the initialization cases.
Note that 'zsh' requires to declare with autoload the functions put in
FPATH directory so there is no gain to configure FPATH for 'zsh' compare
to a bare source of the 'zsh' init script.
Initialize MODULEPATH variable if not defined, with an empty string or
with the content of the init/.modulespath file if it exists and it is
readable. This file contains a list of module paths, one per line or
many per line separated by colon character.
This way of initializing MODULEPATH has been retrieved from C version
init scripts in order for sysadmins to keep a familiar concept to set
default MODULEPATH.
As for MODULESHOME, get 'tclsh' location from Makefile then replace
'@TCLSH@' pattern in shell init scripts with found location rather than
guessing it in the init scripts.
By doing so, same 'tclsh' location search is applied to all init
scripts. Search is performed with 'command' to look at a predefined list
of PATHs in order to be resilient to the current PATH content.
Simplify guess of MODULESHOME location by more relying on 'make'
capabilities than 'perl'.
Adapt init scripts for the different shells to use the MODULESHOME
variable that is replaced during the 'make' process rather than
${MODULESHOME}, $env(MODULESHOME), etc.
By the way, use a replacement pattern closer to what 'configure' is using
with '@MODULESHOME@' rather than '$MODULESHOME' which was confusing in
shell scripts.
