module is a user interface to the Modules package. The
Modules package provides for the dynamic modification of the user's
environment via modulefiles.
Each modulefile contains the information needed to
configure the shell for an application. Once the Modules package is
initialized, the environment can be modified on a per-module basis using the
module command which interprets modulefiles. Typically
modulefiles instruct the module command to alter or set shell
environment variables such as PATH, MANPATH, etc. modulefiles may be
shared by many users on a system and users may have their own collection to
supplement or replace the shared modulefiles.
The modulefiles are added to and removed from the current
environment by the user. The environment changes contained in a
modulefile can be summarized through the module command as
well. If no arguments are given, a summary of the module usage and
sub-commands are shown.
The action for the module command to take is described by
the sub-command and its associated arguments.
The Modules package and the module command are initialized
when a shell-specific initialization script is sourced into the shell. The
script creates the module command, either as an alias or shell
function, creates Modules environment variables, and if enabled to do so, a
snapshot of the environment is saved as either (if BEGINENV=1)
$HOME/.modulesbeginenv or (if BEGINENV=99) whatever
$MODULESBEGINENV points to.
The module alias or function executes the modulecmd
program and has the shell evaluate the command's output. The first argument
to modulecmd specifies the type of shell.
The initialization scripts are kept in
$MODULESHOME/init/<shell> where <shell> is the
name of the sourcing shell. The sh, csh, tcsh, bash, ksh, and zsh shells are
supported by modulecmd. In addition, python, perl, and cmake
"shells" are supported, which writes the environment changes to
stdout as python, perl, or cmake code.
The perl module command is set up with:
use lib $ENV{'MODULESHOME'}."/init";
use perl;
And the python module command is defined with:
import os, sys;
sys.path.insert(0, '@INITPATH@')
from python import module;
Upon invocation modulecmd sources rc files which contain
global, user and modulefile specific setups. These files are interpreted as
modulefiles. See modulefile(4) for detailed information.
Upon invocation of modulecmd module RC files are sourced in the
following order:
Global RC file as specified by ${MODULERCFILE} or ${MODULESHOME}/etc/rc
User specific module RC file ${HOME}/.modulerc
All .modulerc and .version files found during modulefile seeking.
The module command accepts command line switches as its first
parameter. These may be used to control output format of all information
displayed and the module behavior in case of locating and
interpreting module files.
All switches may be entered either in short or long notation. The
following switches are accepted:
- --help, -H
- Give some helpful usage information, and terminates the command.
- --version,
-V
- Lists the current version of the module command, and some configured
option values. The command then terminates without further
processing.
- --force,
-f
- Force active dependency resolution. This will result in modules found on a
prereq command inside a module file being load automatically.
Unloading module files using this switch will result in all required
modules which have been loaded automatically using the -f switch
being unload. This switch is experimental at the moment.
- --terse,
-t
- Display avail and list output in short format.
- --long, -l
- Display avail and list output in long format.
- --human,
-h
- Display short output of the avail and list commands in human
readable format.
- --verbose,
-v
- Enable verbose messages during module command execution.
- --silent,
-s
- Disable verbose messages. Redirect stderr to /dev/null if
stderr is found not to be a tty. This is a useful option for module
commands being written into .cshrc, .login or
.profile files, because some remote shells (as rsh(1)) and
remote execution commands (like rdist) get confused if there is
output on stderr.
- --create,
-c
- Create caches for module avail and module apropos. You must
be granted write access to the ${MODULEHOME}/modulefiles/ directory if you
try to invoke module with the -c option.
- --icase,
-i
- Case insensitive module parameter evaluation. Currently only implemented
for the module apropos command.
- --userlvl
<lvl>, -u <lvl>
- Set the user level to the specified value. The argument of this option may
be one of:
novice, nov Novice
expert, exp Experienced module user
advanced, adv Advanced module user
- help
[modulefile...]
- Print the usage of each sub-command. If an argument is given, print the
Module-specific help information for the modulefile(s).
- add
modulefile...
- load
modulefile...
- Load modulefile(s) into the shell environment.
- rm
modulefile...
- unload
modulefile...
- Remove modulefile(s) from the shell environment.
- swap
[modulefile1] modulefile2
- switch [modulefile1]
modulefile2
- Switch loaded modulefile1 with modulefile2. If
modulefile1 is not specified, then it is assumed to be the currently
loaded module with the same root name as modulefile2.
- show
modulefile...
- display
modulefile...
- Display information about one or more modulefiles. The display
sub-command will list the full path of the modulefile(s) and all
(or most) of the environment changes the modulefile(s) will make if
loaded. (It will not display any environment changes found within
conditional statements.)
- list
- List loaded modules.
- avail
[path...]
- List all available modulefiles in the current MODULEPATH, where the
sorting order is given by the LC_COLLATE locale environment variable.
All directories in the MODULEPATH are recursively searched for
files containing the modulefile magic cookie.
If an argument is given, then each directory in the MODULEPATH
is searched for modulefiles whose pathname match the argument.
Multiple versions of an application can be supported by
creating a subdirectory for the application containing modulefiles for
each version.
- use [-a|--append]
directory...
- Prepend one or more directories to the MODULEPATH environment variable.
The --append flag will append the directory to MODULEPATH.
- unuse
directory...
- Remove one or more directories from the MODULEPATH environment
variable.
- update
- Attempt to reload all loaded modulefiles. The environment will be
reconfigured to match the environment saved in
${HOME}/.modulesbeginenv (if BEGINENV=1) or the file pointed at by
$MODULESBEGINEV (if BEGINENV=99) and the modulefiles will be
reloaded. This is only valid if modules was configured with
--enable-beginenv (which defines BEGINENV), otherwise this will cause a
warning. update will only change the environment variables that the
modulefiles set.
- clear
- Force the Modules package to believe that no modules are currently
loaded.
- purge
- Unload all loaded modulefiles.
- refresh
- Force a refresh of all non-persistent components of currently loaded
modules. This should be used on derived shells where aliases need to be
reinitialized but the environment variables have already been set by the
currently loaded modules.
- whatis
[modulefile...]
- Display the information set up by the module-whatis commands inside
the specified modulefile(s). If no modulefile is specified, all
'whatis' lines will be shown.
- apropos
string
- keyword
string
- Seeks through the 'whatis' informations of all modulefiles for the
specified string. All module-whatis informations matching the
string will be displayed.
- initadd
modulefile...
- Add modulefile(s) to the shell's initialization file in the user's
home directory. The startup files checked (in order) are:
csh - .modules, .cshrc(.ext), .csh_variables, and .login(.ext)
tcsh - .modules, .tcshrc, .cshrc(.ext), .csh_variables, and .login(.ext)
sh and ksh - .modules, .profile(.ext), and .kshenv(.ext)
bash - .modules, .bash_profile, .bash_login, .profile(.ext), and
.bashrc(.ext)
zsh - .modules, .zcshrc(.ext), .zshenv(.ext), and .zlogin(.ext)
If a 'module load' line is found in any of these files, the
modulefile(s) is(are) appended to any existing list of
modulefiles. The 'module load' line must be located in at least one of
the files listed above for any of the 'init' sub-commands to work
properly. If the 'module load' line is found in multiple shell
initialization files, all of the lines are changed.
- initprepend
modulefile [modulefile...]
- Does the same as initadd but prepends the given modules to the
beginning of the list.
- initrm
modulefile...
- Remove modulefile(s) from the shell's initialization files.
- initswitch
modulefile1 modulefile2
- Switch modulefile1 with modulefile2 in the shell's
initialization files.
- initlist
- List all of the modulefiles loaded from the shell's initialization
file.
- initclear
- Clear all of the modulefiles from the shell's initialization files.
modulefiles are written in the Tool Command Language (Tcl)
and are interpreted by modulecmd. modulefiles can use
conditional statements. Thus the effect a modulefile will have on the
environment may change depending upon the current state of the
environment.
Environment variables are unset when unloading a
modulefile. Thus, it is possible to load a modulefile
and then unload it without having the environment variables return to
their prior state.