FreeBSD Manual Pages

home | help

MODULE(1) Modules MODULE(1)

NAME
module - command interface to the Modules package

SYNOPSIS
module [switches] [sub-command [sub-command-args]]

DESCRIPTION
module is a user interface to the Modules package. The Modules package pro-
vides for the dynamic modification of the user's environment via module-
files.

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 inter-
prets modulefiles. Typically modulefiles instruct the module command to al-
ter or set shell environment variables such as PATH, MANPATH, etc. Module-
files may be shared by many users on a system and users may have their own
set 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 summa-
rized through the module command as well. If no arguments are given, a sum-
mary 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.

Package Initialization
The Modules package and the module command are initialized when a
shell-specific initialization script is sourced into the shell. The script
executes the autoinit sub-command of the modulecmd.tcl program located in
/usr/local/Modules/5.6.1/libexec for the corresponding shell. The output of
this execution is evaluated by shell which creates the module command as
either an alias or function and creates Modules environment variables.

During this initialization process, if the Modules environment is found un-
defined (when both MODULEPATH and LOADEDMODULES are found either unset or
empty), the modulespath and initrc configuration files located in /usr/lo-
cal/Modules/5.6.1/etc are evaluated if present and following this order.
modulespath file contains the list of modulepaths to enable during initial-
ization. In this file, the modulepaths are separated by newline or colon
characters. initrc is a modulefile that defines during initialization the
modulepaths to enable, the modules to load and the module configuration to
apply.

During the initialization process, if the Modules environment is found de-
fined a module refresh is automatically applied to restore in the current
environment all non-persistent components set by loaded modules.

The module alias or function executes the modulecmd.tcl program and has the
shell evaluate the command's output. The first argument to modulecmd.tcl
specifies the type of shell.

The initialization scripts are kept in /usr/local/Mod-
ules/5.6.1/init/<shell> where <shell> is the name of the sourcing shell.
For example, a C Shell user sources the /usr/local/Modules/5.6.1/init/csh
script. The sh, csh, tcsh, bash, ksh, zsh, fish and cmd shells are sup-
ported by modulecmd.tcl. In addition, python, perl, ruby, tcl, cmake, r and
lisp "shells" are supported which writes the environment changes to stdout
as python, perl, ruby, tcl, lisp, r or cmake code.

Initialization may also be performed by directly calling the autoinit
sub-command of the modulecmd.tcl program.

A ml alias or function may also be defined at initialization time if en-
abled (see MODULES_ML section). ml is a handy frontend leveraging all mod-
ule command capabilities with less character typed. See ml for detailed in-
formation.

A mogui alias or function may also be defined at initialization time if
mogui-cmd command is found in PATH. mogui is the Graphical User Interface
for Modules. Environment changes performed in the GUI is applied onto the
shell session that executed mogui.

Examples of initialization
C Shell initialization (and derivatives):

source /usr/local/Modules/5.6.1/init/csh
module load modulefile modulefile ...

Bourne Shell (sh) (and derivatives):

. /usr/local/Modules/5.6.1/init/sh
module load modulefile modulefile ...

PowerShell (pwsh):

. /usr/local/Modules/5.6.1/init/pwsh.ps1
envmodule load modulefile modulefile ...

Perl:

require "/usr/local/Modules/5.6.1/init/perl.pm";
&module('load', 'modulefile', 'modulefile', '...');

Python:

import os
exec(open("/usr/local/Modules/5.6.1/init/python.py").read(), globals())
module("load", "modulefile", "modulefile", "...")

Ruby:

require '/usr/local/Modules/5.6.1/init/ruby.rb'
ENVModule.module('load', 'modulefile', 'modulefile', '...')

Bourne Shell (sh) (and derivatives) with autoinit sub-command:

eval "$(/usr/local/Modules/5.6.1/libexec/modulecmd.tcl sh autoinit)"

Modulecmd startup
Upon invocation modulecmd.tcl sources a site-specific configuration script
if it exists. Siteconfig script is a Tcl script located at /usr/local/Mod-
ules/5.6.1/etc/siteconfig.tcl. It enables to supersede any global variable
or procedure definition of modulecmd.tcl. See Site-specific configuration
for detailed information.

Afterward, modulecmd.tcl sources rc files which contain global, user and
modulefile specific setups. These files are interpreted as modulefiles. See
modulefile for detailed information.

Upon invocation of modulecmd.tcl module run-command files are sourced in
the following order:

1. Global RC file(s) as specified by MODULERCFILE variable or /usr/lo-
cal/Modules/5.6.1/etc/rc. If a path element in MODULERCFILE points to a
directory, the modulerc file in this directory is used as a global RC
file.

2. User specific module RC file $HOME/.modulerc

3. All .modulerc and .version files found during modulefile seeking.

These module run-command files must begins like modulefiles with the #%Mod-
ule file signature, also called the Modules magic cookie. A version number
may be placed after this string. The version number reflects the minimum
version of modulecmd.tcl required to interpret the run-command file. If a
version number doesn't exist, then modulecmd.tcl will assume the run-com-
mand file is compatible. Files without the magic cookie or with a version
number greater than the current version of modulecmd.tcl will not be inter-
preted and an error is reported. Such error does not abort the whole module
evaluation. If the mcookie_version_check configuration is disabled the ver-
sion number set is not checked.

NOTE:
Run-command files are intended to set parameters for modulefiles, not to
configure the module command itself.

Command line switches
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 modulefiles.

All switches may be entered either in short or long notation. The following
switches are accepted:

--all, -a
Include hidden modules in search performed with avail, aliases,
list, lint, savelist, search, spider or whatis sub-commands.
Hard-hidden modules are not affected by this option.

--auto
Enable automated module handling mode on sub-commands that load or
unload modulefiles. See also MODULES_AUTO_HANDLING section.

--color=<WHEN>
Colorize the output. WHEN defaults to always or can be never or
auto. See also MODULES_COLOR section.

--contains, -C
On avail, list, savelist and spider sub-commands, return modules or
collections whose fully qualified name contains search query string.

--debug, -D, -DD
Debug mode. Causes module to print debugging messages about its
progress. Multiple -D options increase the debug verbosity. The max-
imum is 2.

--default, -d
On avail and spider sub-commands, display only the default version
of each module name. Default version is the explicitly set default
version or also the implicit default version if the configuration
option implicit_default is enabled (see Locating Modulefiles section
in the modulefile man page for further details on implicit default
version).

--dumpname
Report the name of the current implementation of the module command.
This option returns Modules for this implementation. The command
then terminates without further processing.

--force, -f
On load, unload, switch, load-any, try-load, mod-to-sh and source
sub-commands by-pass any unsatisfied modulefile constraint corre-
sponding to the declared prereq, via requirement and conflict. Which
means for instance that a modulefile will be loaded even if it comes
in conflict with another loaded modulefile or that a modulefile will
be unloaded even if it is a requirement of another modulefile.

On load, ml, mod-to-sh, purge, reload, switch, try-load and unload
sub-commands applies continue on error behavior when an error occurs
even if abort_on_error option is enabled.

On ml, purge, reload, reset, restore, stash, stashpop, switch and
unload sub-commands, unloads modulefile anyway even if an evaluation
error occurs.

On clear sub-command, skip the confirmation dialog and proceed.

On purge sub-command also unload sticky modules and modulefiles that
are depended by non-unloadable modules.

--help, -h
Give some helpful usage information, and terminates the command.

--icase, -i
Match module specification arguments in a case insensitive manner.

--ignore-cache
Ignore module cache.

--ignore-user-rc
Skip evaluation of user-specific module rc file ($HOME/.modulerc).

--indepth
On avail and spider sub-commands, include in search results the
matching modulefiles and directories and recursively the modulefiles
and directories contained in these matching directories.

--json, -j
Display avail, list, savelist, search, spider, stashlist and whatis
output in JSON format.

--latest, -L
On avail and spider sub-commands, display only the highest numeri-
cally sorted version of each module name (see Locating Modulefiles
section in the modulefile man page).

--long, -l
Display avail, list, savelist, spider and stashlist output in long
format.

--no-auto
Disable automated module handling mode on sub-commands that load or
unload modulefiles. See also MODULES_AUTO_HANDLING section.

--no-indepth
On avail and spider sub-commands, limit search results to the match-
ing modulefiles and directories found at the depth level expressed
by the search query. Thus modulefiles contained in directories part
of the result are excluded.

--no-pager
Do not pipe message output into a pager.

--no-redirect
Do not send message output to stdout. Keep it on stderr.

--output=LIST, -o LIST
Define the content to report in addition to module names. This op-
tion is supported by avail, list and spider sub-commands on their
regular or terse output modes. Accepted values are a LIST of ele-
ments to report separated by colon character (:). The order of the
elements in LIST does not matter.

Accepted elements in LIST for avail and spider sub-command are: mod-
ulepath, alias, provided-alias, dirwsym, indesym, sym, tag, key,
hidden, variant, variantifspec and via. via element is not accepted
on terse output mode.

Accepted elements in LIST for list sub-command are: header, idx,
variant, alias, indesym, sym, tag, hidden and key.

The order of the elements in LIST does not matter. Module names are
the only content reported when LIST is set to an empty value.

LIST may be prefixed by + or - character to indicate respectively to
append it to or subtract it from current configuration option value.

See also MODULES_AVAIL_OUTPUT, MODULES_LIST_OUTPUT and
MODULES_SPIDER_OUTPUT.

--paginate
Pipe all message output into less (or if set, to the command re-
ferred in MODULES_PAGER variable) if error output stream is a termi-
nal. See also MODULES_PAGER section.

--redirect
Send message output to stdout instead of stderr. Only supported on
sh, bash, ksh, zsh and fish shells.

--silent, -s
Turn off error, warning and informational messages. module command
output result is not affected by silent mode.

--starts-with, -S
On avail, list, savelist and spider sub-commands, return modules or
collections whose name starts with search query string.

--tag=LIST
On load, load-any, switch and try-load sub-commands, apply LIST of
module tags to the loading modulefile. LIST corresponds to the con-
catenation of multiple tags separated by colon character (:). LIST
should not contain tags inherited from modulefile state or from
other modulefile commands. If module is already loaded, tags from
LIST are added to the list of tags already applied to this module.

--terse, -t
Display avail, list, savelist, spider and stashlist output in short
format.

--timer
Prints at the end of the output an evaluation of the total execution
time of the module command. When mixed with a single or multiple
--debug options, replaces regular debug messages by reports of the
execution time of every internal procedure calls.

--trace, -T
Trace mode. Report details on module searches, resolutions, selec-
tions and evaluations in addition to printing verbose messages.

--verbose, -v, -vv
Enable verbose messages during module command execution. Multiple -v
options increase the verbosity level. The maximum is 2.

--version, -V
Lists the current version of the module command. The command then
terminates without further processing.

--width=COLS, -w COLS
Set the width of the output to COLS columns. See also
MODULES_TERM_WIDTH section.

Module Sub-Commands
add [options] modulefile...
See load.

add-any [options] modulefile...
See load-any.

aliases [-a]
List all available symbolic version-names and aliases in the current
MODULEPATH. All directories in the MODULEPATH are recursively
searched in the same manner than for the avail sub-command. Only the
symbolic version-names and aliases found in the search are dis-
played.

append-path [options] variable value...
Append value to environment variable. The variable is a colon, or
delimiter, separated list. See append-path in the modulefile man
page for options description and further explanation.

When append-path is called as a module sub-command, the reference
counter variable, which denotes the number of times value has been
added to environment variable, is not updated unless if the --dupli-
cates option is set.

apropos [-a] [-j] string
See search.

avail [-d|-L] [-t|-l|-j] [-a] [-o LIST] [-S|-C] [--indepth|--no-indepth]
[pattern...]
List all available modulefiles in the current MODULEPATH. All direc-
tories in the MODULEPATH are recursively searched for files contain-
ing the Modules magic cookie. If a pattern argument is given, then
each directory in the MODULEPATH is searched for modulefiles whose
pathname, symbolic version-name or alias match pattern in a case in-
sensitive manner by default. pattern may contain wildcard charac-
ters. Multiple versions of an application can be supported by cre-
ating a subdirectory for the application containing modulefiles for
each version.

Symbolic version-names and aliases found in the search are displayed
in the result of this sub-command. Symbolic version-names are dis-
played next to the modulefile they are assigned to within parenthe-
sis. Aliases are listed in the MODULEPATH section where they have
been defined. To distinguish aliases from modulefiles a @ symbol is
added within parenthesis next to their name. Aliases defined through
a global or user specific module RC file are listed under the
global/user modulerc section.

When colored output is enabled and a specific graphical rendition is
defined for module default version, the default symbol is omitted
and instead the defined graphical rendition is applied to the rela-
tive modulefile. When colored output is enabled and a specific
graphical rendition is defined for module alias, the @ symbol is
omitted. The defined graphical rendition applies to the module alias
name. See MODULES_COLOR and MODULES_COLORS sections for details on
colored output.

Module tags applying to the available modulefiles returned by the
avail sub-command are reported along the module name they are asso-
ciated to (see Module tags section).

Module variants and their available values may be reported along the
module name they belong to (see Module variants section) if defined
in avail output configuration option (see --output/-o option). The
Extra match search process is triggered to collect variant informa-
tion.

A Key section is added at the end of the output in case some ele-
ments are reported in parentheses or chevrons along module name or
if some graphical rendition is made over some output elements. This
Key section gives hints on the meaning of such elements.

The parameter pattern may also refer to a symbolic modulefile name
or a modulefile alias. It may also leverage a specific syntax to
finely select module version (see Advanced module version specifiers
section below).

If pattern contains variant specification or Extra specifier, the
Extra match search process is triggered to collect command informa-
tion used in modulefiles. Modules are included in results only if
they match pattern variant specification and extra specifier. pat-
tern may be a bare variant specification or extra specifier without
mention of a module name.

When several patterns are provided all modulefiles matching at least
one of these patterns are listed.

cachebuild [modulepath...]
Build module cache file for designated modulepaths. If no argument
is provided cache file is built for every modulepath currently en-
abled. Cache file creation is skipped for modulepaths where user
cannot write in.

The name and content of every readable modulefiles and rc files are
recorded into cache file. Also last modification time of modulefiles
and invalid modulefile error messages are recorded. With all these
information, the sole cache file is evaluated to know what is avail-
able within modulepath.

See Module cache section for more details on module cache mechanism.

cacheclear
Delete module cache file in every modulepath currently enabled. If
user cannot write in a modulepath directory, cache file deletion is
skipped for this modulepath.

See Module cache section for more details on module cache mechanism.

clear [-f]
Force the Modules package to believe that no modules are currently
loaded. A confirmation is requested if command-line switch -f (or
--force) is not passed. Typed confirmation should equal to yes or y
in order to proceed.

config [--dump-state|name [value]|--reset name]
Gets or sets modulecmd.tcl options. Reports the currently set value
of passed option name or all existing options if no name passed. If
a name and a value are provided, the value of option name is set to
value. If command-line switch --reset is passed in addition to a
name, overridden value for option name is cleared.

When a reported option value differs from default value a mention is
added to indicate whether the overridden value is coming from a com-
mand-line switch (cmd-line) or from an environment variable
(env-var). When a reported option value is locked and cannot be al-
tered a (locked) mention is added.

If no value is currently set for an option name, the mention <undef>
is reported.

For options whose value is a colon-separated list, value may be pre-
fixed by + or - character. It indicates respectively to append it to
or subtract it from current option value.

When command-line switch --dump-state is passed, current mod-
ulecmd.tcl state and Modules-related environment variables are re-
ported in addition to currently set modulecmd.tcl options.

Existing option names are:

abort_on_error
List of module sub-commands that abort evaluation sequence
when an error is raised by an evaluated module. Evaluations
already performed are withdrawn and remaining modules to
evaluate are skipped.

This configuration option can be changed at installation time
with --with-abort-on-error option. The MODULES_ABORT_ON_ERROR
environment variable is defined by config sub-command when
changing this configuration option from its default value.
See MODULES_ABORT_ON_ERROR description for details.

advanced_version_spec
Advanced module version specification to finely select mod-
ulefiles.

Default value is 1. It can be changed at installation time
with --disable-advanced-version-spec option. The
MODULES_ADVANCED_VERSION_SPEC environment variable is defined
by config sub-command when changing this configuration option
from its default value. See MODULES_ADVANCED_VERSION_SPEC de-
scription for details.

auto_handling
Automated module handling mode.

Default value is 1. It can be changed at installation time
with --disable-auto-handling option. The
MODULES_AUTO_HANDLING environment variable is defined by
config sub-command when changing this configuration option
from its default value. The --auto and --no-auto command line
switches change the value of this configuration option. See
MODULES_AUTO_HANDLING description for details.

avail_indepth
avail sub-command in depth search mode.

Default value is 1. It can be changed at installation time
with --disable-avail-indepth option. The
MODULES_AVAIL_INDEPTH environment variable is defined by
config sub-command when changing this configuration option
from its default value. The --indepth and --no-indepth com-
mand line switches change the value of this configuration op-
tion. See MODULES_AVAIL_INDEPTH description for details.

avail_output
Content to report in addition to module names on avail
sub-command regular output mode.

Default value is modulepath:alias:dirwsym:sym:tag:variantif-
spec:key. It can be changed at installation time with
--with-avail-output option. The MODULES_AVAIL_OUTPUT environ-
ment variable is defined by config sub-command when changing
this configuration option from its default value. The
--output/-o command line switches change the value of this
configuration option. See MODULES_AVAIL_OUTPUT description
for details.

avail_terse_output
Content to report in addition to module names on avail
sub-command terse output mode.

Default value is modulepath:alias:dirwsym:sym:tag:variantif-
spec. It can be changed at installation time with
--with-avail-terse-output option. The
MODULES_AVAIL_TERSE_OUTPUT environment variable is defined by
config sub-command when changing this configuration option
from its default value. The --output/-o command line switches
change the value of this configuration option. See
MODULES_AVAIL_TERSE_OUTPUT description for details.

cache_buffer_bytes
Size of the buffer used when reading or writing cache files.

Default value is 32768. Values between 4096 and 1000000 are
accepted. The MODULES_CACHE_BUFFER_BYTES environment vari-
able is defined by config sub-command when changing this con-
figuration option from its default value.

cache_expiry_secs
Number of seconds a cache file is considered valid after be-
ing generated.

Default value is 0. Values between 0 and 31536000 are ac-
cepted. The MODULES_CACHE_EXPIRY_SECS environment variable
is defined by config sub-command when changing this configu-
ration option from its default value.

collection_pin_version
Register exact modulefile version in collection.

Default value is 0. The MODULES_COLLECTION_PIN_VERSION envi-
ronment variable is defined by config sub-command when chang-
ing this configuration option from its default value. See
MODULES_COLLECTION_PIN_VERSION description for details.

collection_pin_tag
Register full tag list applying to modulefiles in collection.

Default value is 0. The MODULES_COLLECTION_PIN_TAG environ-
ment variable is defined by config sub-command when changing
this configuration option from its default value. See
MODULES_COLLECTION_PIN_TAG description for details.

collection_target
Collection target which is valid for current system.

This configuration option is unset by default. The
MODULES_COLLECTION_TARGET environment variable is defined by
config sub-command when changing this configuration option
from its default value. See MODULES_COLLECTION_TARGET de-
scription for details.

color Colored output mode.

Default value is auto. It can be changed at installation time
with --disable-color option. The MODULES_COLOR environment
variable is defined by config sub-command when changing this
configuration option from its default value. The --color com-
mand line switches changes the value of this configuration
option. See MODULES_COLOR description for details.

colors
Chosen colors to highlight output items.

Default value is
hi=1:db=2:tr=2:se=2:er=91:wa=93:me=95:in=94:mp=1;94:di=94:al=96:va=93:sy=95:de=4:cm=92:aL=100:L=90;47:H=2:F=41:nF=31;43:S=46:sS=44:kL=30;48;5;109:W=30;43.
It can be changed at installation time with
--with-dark-background-colors or
--with-light-background-colors options in conjunction with
--with-terminal-background. The MODULES_COLORS environment
variable is defined by config sub-command when changing this
configuration option from its default value. See
MODULES_COLORS description for details.

conflict_unload
Automated unload of conflicting modules when loading a mod-
ule. This mechanism is part of the automated module handling
mode and also requires enablement of auto_handling configura-
tion option.

Default value is 0. It can be changed at installation time
with --enable-conflict-unload option. The
MODULES_CONFLICT_UNLOAD environment variable is defined by
config sub-command when changing this configuration option
from its default value. See MODULES_CONFLICT_UNLOAD descrip-
tion for details.

contact
Modulefile contact address.

Default value is root@localhost. The MODULECONTACT environ-
ment variable is defined by config sub-command when changing
this configuration option from its default value. See
MODULECONTACT description for details.

extended_default
Allow partial module version specification.

Default value is 1. It can be changed at installation time
with --disable-extended-default option. The
MODULES_EXTENDED_DEFAULT environment variable is defined by
config sub-command when changing this configuration option
from its default value. See MODULES_EXTENDED_DEFAULT descrip-
tion for details.

editor
Text editor command to open modulefile with through edit
sub-command.

Default value is vi. It can be changed at installation time
with --with-editor option. The MODULES_EDITOR environment
variable is defined by config sub-command when changing this
configuration option from its default value. See
MODULES_EDITOR description for details.

extra_siteconfig
Additional site-specific configuration script location. See
Site-specific configuration section for details.

This configuration option is unset by default. The
MODULES_SITECONFIG environment variable is defined by config
sub-command when changing this configuration option from its
default value. See MODULES_SITECONFIG description for de-
tails.

hide_auto_loaded
Tag automatically loaded modules hidden-loaded

Default is 0. The MODULES_HIDE_AUTO_LOADED environment vari-
able is defined by config sub-command when changing this con-
figuration option from its default value.

home Location of Modules package main directory.

Default value is /usr/local/Modules/5.6.1. It can be changed
at installation time with --prefix or --with-moduleshome op-
tions. The MODULESHOME environment variable is defined by
config sub-command when changing this configuration option
from its default value. See MODULESHOME description for de-
tails.

icase Enable case insensitive match.

Default value is search. It can be changed at installation
time with --with-icase option. The MODULES_ICASE environment
variable is defined by config sub-command when changing this
configuration option from its default value. The --icase/-i
command line switches change the value of this configuration
option. See MODULES_ICASE description for details.

ignore_cache
Ignore module cache.

Default is 0. The MODULES_IGNORE_CACHE environment variable
is defined by config sub-command when changing this configu-
ration option from its default value. The --ignore-cache com-
mand line switch changes the value of this configuration op-
tion.

ignore_user_rc
Skip evaluation of user-specific module rc file ($HOME/.mod-
ulerc).

Default is 0. The MODULES_IGNORE_USER_RC environment variable
is defined by config sub-command when changing this configu-
ration option from its default value. The --ignore-user-rc
command line switch changes the value of this configuration
option.

ignored_dirs
Directories ignored when looking for modulefiles.

Default value is CVS RCS SCCS .svn .git .SYNC .sos. The value
of this option cannot be altered.

implicit_default
Set an implicit default version for modules.

Default value is 1. It can be changed at installation time
with --disable-implicit-default option. The
MODULES_IMPLICIT_DEFAULT environment variable is defined by
config sub-command when changing this configuration option
from its default value. See MODULES_IMPLICIT_DEFAULT descrip-
tion for details.

implicit_requirement
Implicitly define a requirement onto modules specified on
module commands in modulefile.

Default value is 1. It can be changed at installation time
with --disable-implicit-requirement option. The
MODULES_IMPLICIT_REQUIREMENT environment variable is defined
by config sub-command when changing this configuration option
from its default value. See MODULES_IMPLICIT_REQUIREMENT de-
scription for details.

list_output
Content to report in addition to module names on list
sub-command regular output mode.

Default value is header:idx:variant:sym:tag:key. It can be
changed at installation time with --with-list-output option.
The MODULES_LIST_OUTPUT environment variable is defined by
config sub-command when changing this configuration option
from its default value. The --output/-o command line switches
change the value of this configuration option. See
MODULES_LIST_OUTPUT description for details.

list_terse_output
Content to report in addition to module names on list
sub-command terse output mode.

Default value is header. It can be changed at installation
time with --with-list-terse-output option. The
MODULES_LIST_TERSE_OUTPUT environment variable is defined by
config sub-command when changing this configuration option
from its default value. The --output/-o command line switches
change the value of this configuration option. See
MODULES_LIST_TERSE_OUTPUT description for details.

locked_configs
Configuration options that cannot be superseded. All options
referred in locked_configs value are locked, thus their value
cannot be altered.

This configuration option is set to an empty value by de-
fault. It can be changed at installation time with
--with-locked-configs option. The value of this option can-
not be altered.

logged_events
List of the events to log.

This configuration option is set to an empty value by de-
fault. It can be changed at installation time with
--with-logged-events option. The MODULES_LOGGED_EVENTS envi-
ronment variable is defined by config sub-command when chang-
ing this configuration option from its default value. See
MODULES_LOGGED_EVENTS description for details.

logger
Command to log messages.

Default value is logger -t modules. It can be changed at in-
stallation time with --with-logger and --with-logger-opts op-
tions. The MODULES_LOGGER environment variable is defined by
config sub-command when changing this configuration option
from its default value. See MODULES_LOGGER description for
details.

mcookie_check
Defines if the Modules magic cookie (i.e., #%Module file sig-
nature) should be checked to determine if a file is a module-
file.

Default value is always. The MODULES_MCOOKIE_CHECK environ-
ment variable is defined by config sub-command when changing
this configuration option from its default value. See
MODULES_MCOOKIE_CHECK description for details.

mcookie_version_check
Defines if the version set in the Modules magic cookie used
in modulefile should be checked against the version of mod-
ulecmd.tcl to determine if the modulefile could be evaluated
or not.

Default value is 1. It can be changed at installation time
with --disable-mcookie-version-check option. The
MODULES_MCOOKIE_VERSION_CHECK environment variable is defined
by config sub-command when changing this configuration option
from its default value. See MODULES_MCOOKIE_VERSION_CHECK de-
scription for details.

ml Define ml command at initialization time.

Default value is 1. It can be changed at installation time
with --disable-ml option. The MODULES_ML environment variable
is defined by config sub-command when changing this configu-
ration option from its default value. See MODULES_ML descrip-
tion for details.

nearly_forbidden_days
Set the number of days a module should be considered nearly
forbidden prior reaching its expiry date.

Default value is 14. It can be changed at installation time
with --with-nearly-forbidden-days option. The
MODULES_NEARLY_FORBIDDEN_DAYS environment variable is defined
by config sub-command when changing this configuration option
from its default value. See MODULES_NEARLY_FORBIDDEN_DAYS de-
scription for details.

pager Text viewer to paginate message output.

Default value is less -eFKRX. It can be changed at installa-
tion time with --with-pager and --with-pager-opts options.
The MODULES_PAGER environment variable is defined by config
sub-command when changing this configuration option from its
default value. See MODULES_PAGER description for details.

protected_envvars
Prevents any modification of listed environment variables
(colon : separator).

This configuration option is unset by default. The
MODULES_PROTECTED_ENVVARS environment variable is defined by
config sub-command when changing this configuration option
from its default value. See MODULES_PROTECTED_ENVVARS de-
scription for details.

quarantine_support
Defines if code for quarantine mechanism support should be
generated in module shell function definition.

Default value is 0. It can be changed at installation time
with --enable-quarantine-support option. The
MODULES_QUARANTINE_SUPPORT environment variable is defined by
config sub-command when changing this configuration option
from its default value. See MODULES_QUARANTINE_SUPPORT de-
scription for details.

rcfile
Location of global run-command file(s).

This configuration option is unset by default. The
MODULERCFILE environment variable is defined by config
sub-command when changing this configuration option from its
default value. See MODULERCFILE description for details.

redirect_output
Control whether or not the output of module command should be
redirected from stderr to stdout.

Default value is 1. The MODULES_REDIRECT_OUTPUT environment
variable is defined by config sub-command when changing this
configuration option from its default value. The --redirect
and --no-redirect command line switches change the value of
this configuration option. See MODULES_REDIRECT_OUTPUT de-
scription for details.

require_via
Consider loaded module enabling a modulepath a requirement
for loaded modules stored in this modulepath.

Default value is 0. It can be changed at installation time
with --enable-require-via option. The MODULES_REQUIRE_VIA en-
vironment variable is defined by config sub-command when
changing this configuration option from its default value.
See MODULES_REQUIRE_VIA description for details.

reset_target_state
Control behavior of reset sub-command. Whether environment
should be purged (__purge__), initial environment (__init__)
or a named collection (any other value) should restored.

Default value is __init__. The MODULES_RESET_TARGET_STATE en-
vironment variable is defined by config sub-command when
changing this configuration option from its default value.
See MODULES_RESET_TARGET_STATE description for details.

run_quarantine
Environment variables to indirectly pass to modulecmd.tcl.

This configuration option is set to an empty value by de-
fault. It can be changed at installation time with
--with-quarantine-vars option that sets
MODULES_RUN_QUARANTINE. This environment variable is also de-
fined by config sub-command when changing this configuration
option. See MODULES_RUN_QUARANTINE description for details.

search_match
Module search match style.

Default value is starts_with. It can be changed at installa-
tion time with --with-search-match option. The
MODULES_SEARCH_MATCH environment variable is defined by
config sub-command when changing this configuration option
from its default value. The --contains and --starts-with com-
mand line switches change the value of this configuration op-
tion. See MODULES_SEARCH_MATCH description for details.

set_shell_startup
Ensure module command definition by setting shell startup
file.

Default value is 0. It can be changed at installation time
with --enable-set-shell-startup option. The
MODULES_SET_SHELL_STARTUP environment variable is defined by
config sub-command when changing this configuration option
from its default value. See MODULES_SET_SHELL_STARTUP de-
scription for details.

shells_with_ksh_fpath
Ensure module command is defined in ksh when it is started as
a sub-shell from the listed shells.

This configuration option is set to an empty value by de-
fault. The MODULES_SHELLS_WITH_KSH_FPATH environment variable
is defined by config sub-command when changing this configu-
ration option from its default value. See
MODULES_SHELLS_WITH_KSH_FPATH description for details.

silent_shell_debug
Disablement of shell debugging property for the module com-
mand. Also defines if code to silence shell debugging prop-
erty should be generated in module shell function definition.

Default value is 0. It can be changed at installation time
with --enable-silent-shell-debug-support option. The
MODULES_SILENT_SHELL_DEBUG environment variable is defined by
config sub-command when changing this configuration option
from its default value. See MODULES_SILENT_SHELL_DEBUG de-
scription for details.

siteconfig
Primary site-specific configuration script location. See
Site-specific configuration section for details.

Default value is /usr/local/Modules/5.6.1/etc/siteconfig.tcl.
It can be changed at installation time with --prefix or
--etcdir options. The value of this option cannot be altered.

source_cache
Cache content of files evaluated in modulefile through
source(n) Tcl command.

Default value is 0. It can be changed at installation time
with --enable-source-cache option. The MODULES_SOURCE_CACHE
environment variable is defined by config sub-command when
changing this configuration option from its default value.
See MODULES_SOURCE_CACHE description for details.

spider_indepth
spider sub-command in depth search mode.

Default value is 1. It can be changed at installation time
with --disable-spider-indepth option. The
MODULES_SPIDER_INDEPTH environment variable is defined by
config sub-command when changing this configuration option
from its default value. The --indepth and --no-indepth com-
mand line switches change the value of this configuration op-
tion. See MODULES_SPIDER_INDEPTH description for details.

spider_output
Content to report in addition to module names on spider
sub-command regular output mode.

Default value is modulepath:alias:dirwsym:sym:tag:variantif-
spec:via:key. It can be changed at installation time with
--with-spider-output option. The MODULES_SPIDER_OUTPUT envi-
ronment variable is defined by config sub-command when chang-
ing this configuration option from its default value. The
--output/-o command line switches change the value of this
configuration option. See MODULES_SPIDER_OUTPUT description
for details.

spider_terse_output
Content to report in addition to module names on spider
sub-command terse output mode.

Default value is modulepath:alias:dirwsym:sym:tag:variantif-
spec. It can be changed at installation time with
--with-spider-terse-output option. The
MODULES_SPIDER_TERSE_OUTPUT environment variable is defined
by config sub-command when changing this configuration option
from its default value. The --output/-o command line switches
change the value of this configuration option. See
MODULES_SPIDER_TERSE_OUTPUT description for details.

sticky_purge
Error behavior when unloading sticky or super-sticky module
during a module purge.

Raise an error (default) or emit a warning or be silent. It
can be changed at installation time with --with-sticky-purge
option. The MODULES_STICKY_PURGE environment variable is de-
fined by config sub-command when changing this configuration
option from its default value. See MODULES_STICKY_PURGE de-
scription for details.

tag_abbrev
Abbreviations to use to report module tags.

Default value is auto-loaded=aL:loaded=L:hidden=H:hid-
den-loaded=H:forbidden=F:nearly-forbidden=nF:sticky=S:su-
per-sticky=sS:keep-loaded=kL:warning=W. It can be changed at
installation time with --with-tag-abbrev option. The
MODULES_TAG_ABBREV environment variable is defined by config
sub-command when changing this configuration option from its
default value. See MODULES_TAG_ABBREV description for de-
tails.

tag_color_name
Tags whose name should be colored instead of module name.

This configuration option is set to an empty value by de-
fault. It can be changed at installation time with
--with-tag-color-name option. The MODULES_TAG_COLOR_NAME en-
vironment variable is defined by config sub-command when
changing this configuration option from its default value.
See MODULES_TAG_COLOR_NAME description for details.

tcl_ext_lib
Modules Tcl extension library location.

Default value is @libdir@/libtclenvmodules.so. It can be
changed at installation time with --prefix or --libdir op-
tions. The value of this option cannot be altered.

tcl_linter
Command to check syntax of modulefiles with through lint
sub-command.

Default value is nagelfar.tcl. It can be changed at installa-
tion time with --with-tcl-linter and --with-tcl-linter-opts
options. The MODULES_TCL_LINTER environment variable is de-
fined by config sub-command when changing this configuration
option from its default value. See MODULES_TCL_LINTER de-
scription for details.

term_background
Terminal background color kind.

Default value is dark. It can be changed at installation time
with --with-terminal-background option. The
MODULES_TERM_BACKGROUND environment variable is defined by
config sub-command when changing this configuration option
from its default value. See MODULES_TERM_BACKGROUND descrip-
tion for details.

term_width
Set the width of the output.

Default value is 0. The MODULES_TERM_WIDTH environment vari-
able is defined by config sub-command when changing this con-
figuration option from its default value. The --width/-w com-
mand line switches change the value of this configuration op-
tion. See MODULES_TERM_WIDTH description for details.

unique_name_loaded
Only one module loaded per module name.

Default value is 0. It can be changed at installation time
with --enable-unique-name-loaded option. The
MODULES_UNIQUE_NAME_LOADED environment variable is defined by
config sub-command when changing this configuration option
from its default value. See MODULES_UNIQUE_NAME_LOADED de-
scription for details.

unload_match_order
Unload firstly loaded or lastly loaded module matching re-
quest.

Default value is returnlast. It can be changed at installa-
tion time with --with-unload-match-order option. The
MODULES_UNLOAD_MATCH_ORDER environment variable is defined by
config sub-command when changing this configuration option
from its default value. See MODULES_UNLOAD_MATCH_ORDER de-
scription for details.

variant_shortcut
Shortcut characters that could be used to specify or report
module variants.

This configuration option is set to an empty value by de-
fault. It can be changed at installation time with
--with-variant-shortcut option. The MODULES_VARIANT_SHORTCUT
environment variable is defined by config sub-command when
changing this configuration option from its default value.
See MODULES_VARIANT_SHORTCUT description for details.

verbosity
Module command verbosity level.

Default value is normal. It can be changed at installation
time with --with-verbosity option. The MODULES_VERBOSITY en-
vironment variable is defined by config sub-command when
changing this configuration option from its default value.
The --debug/-D, --silent/-s, --trace/-T and --verbose/-v com-
mand line switches change the value of this configuration op-
tion. See MODULES_VERBOSITY description for details.

wa_277
Workaround for Tcsh history issue.

Default value is 0. It can be changed at installation time
with --enable-wa-277 option. The MODULES_WA_277 environment
variable is defined by config sub-command when changing this
configuration option from its default value. See
MODULES_WA_277 description for details.

describe [collection]
See saveshow.

disable [collection]
See saverm.

display modulefile...
Display information about one or more modulefiles. The display
sub-command will list the full path of the modulefile and the envi-
ronment changes the modulefile will make if loaded. (Note: It will
not display any environment changes found within conditional state-
ments.)

The parameter modulefile may also be a symbolic modulefile name or a
modulefile alias. It may also leverage a specific syntax to finely
select module version (see Advanced module version specifiers sec-
tion below).

When several modulefiles are passed, they are evaluated sequentially
in the specified order. If one modulefile evaluation raises an er-
ror, display sequence continues.

edit modulefile
Open modulefile for edition with text editor command designated by
the editor configuration option.

help [modulefile...]
Print the usage of each sub-command. If an argument is given, print
the Module-specific help information for the modulefile.

When several modulefiles are passed, they are evaluated sequentially
in the specified order. If one modulefile evaluation raises an er-
ror, help sequence continues.

info-loaded modulefile
Returns the names of currently loaded modules matching passed mod-
ulefile. Returns an empty string if passed modulefile does not
match any loaded modules. See module-info loaded in the modulefile
man page for further explanation.

initadd modulefile...
Add modulefile to the shell's initialization file in the user's home
directory. The startup files checked (in order) are:

C Shell
.modules, .cshrc, .csh_variables and .login

TENEX C Shell
.modules, .tcshrc, .cshrc, .csh_variables and .login

Bourne and Korn Shells
.modules, .profile

GNU Bourne Again Shell
.modules, .bash_profile, .bash_login, .profile and .bashrc

Z Shell
.modules, .zshrc, .zshenv and .zlogin

Friendly Interactive Shell
.modules, .config/fish/config.fish

If a module load line is found in any of these files, the module-
files 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.

initclear
Clear all of the modulefiles from the shell's initialization files.

initlist
List all of the modulefiles loaded from the shell's initialization
file.

initprepend modulefile...
Does the same as initadd but prepends the given modules to the be-
ginning of the list.

initrm modulefile...
Remove modulefile from the shell's initialization files.

initswitch modulefile1 modulefile2
Switch modulefile1 with modulefile2 in the shell's initialization
files.

is-avail modulefile...
Returns a true value if any of the listed modulefiles exists in en-
abled MODULEPATH. Returns a false value otherwise. See is-avail in
the modulefile man page for further explanation.

is-loaded [modulefile...]
Returns a true value if any of the listed modulefiles has been
loaded or if any modulefile is loaded in case no argument is pro-
vided. Returns a false value otherwise. See is-loaded in the
modulefile man page for further explanation.

is-saved [collection...]
Returns a true value if any of the listed collections exists or if
any collection exists in case no argument is provided. Returns a
false value otherwise. See is-saved in the modulefile man page for
further explanation.

is-used [directory...]
Returns a true value if any of the listed directories has been en-
abled in MODULEPATH or if any directory is enabled in case no argu-
ment is provided. Returns a false value otherwise. See is-used in
the modulefile man page for further explanation.

keyword [-a] [-j] string
See search.

lint [-a] [modulefile...]
Analyze syntax of one or more modulefiles with the linter command
designated by the tcl_linter configuration option.

If no modulefile is specified, all the modulefiles and modulerc
available in enabled modulepaths are analyzed as well as global rc,
user rc and modulecache files . Hidden modulefiles are also analyzed
when --all/-a option is set.

When nagelfar.tcl is the selected linter command, a static Tcl syn-
tax analysis is performed. In addition, syntax of modulefile com-
mands are checked in these files based on their kind (global/user
rc, modulerc, modulecache or modulefile).

list [-t|-l|-j] [-a] [-o LIST] [-S|-C] [pattern...]
List loaded modules. If a pattern is given, then the loaded modules
are filtered to only list those whose name matches this pattern. It
may contain wildcard characters. pattern is matched in a case insen-
sitive manner by default. If multiple patterns are given, loaded
module has to match at least one of them to be listed.

Module tags applying to the loaded modules are reported along the
module name they are associated to (see Module tags section).

Module variants selected on the loaded modules are reported along
the module name they belong to (see Module variants section).

If pattern contains variant specification, loaded modules are in-
cluded in results only if they match it. pattern may be a bare vari-
ant specification without mention of a module name.

load [options] modulefile...
Load modulefile into the shell environment.

load command accepts the following options:

* --auto|--no-auto

* -f|--force

* --tag=taglist

Once loaded, the loaded module tag is associated to the loaded mod-
ule. If module has been automatically loaded by another module, the
auto-loaded tag is associated instead (see Module tags section).

When several modulefiles are passed, they are loaded sequentially in
the specified order. If one modulefile evaluation raises an error,
load sequence continues: loaded modules prior the evaluation error
are kept loaded and sequence is resumed with the load of remaining
modulefile in list. Conversely, load sequence is aborted and al-
ready loaded modulefiles are withdrawn if load sub-command is de-
fined in abort_on_error configuration option and --force option is
not set.

The --tag option accepts a list of module tags to apply to module-
file once loaded. If module is already loaded, tags from taglist are
added to the list of tags already applied to this module.

load-any [options] modulefile...
Load into the shell environment one of the modulefile specified. Try
to load each modulefile specified in list from the left to the right
until one got loaded or is found already loaded. Do not complain if
modulefile cannot be found. But if its evaluation fails, an error is
reported and next modulefile in list is evaluated.

load-any command accepts the following options:

* --auto|--no-auto

* -f|--force

* --tag=taglist

The --tag option accepts a list of module tags to apply to module-
file once loaded. If module is already loaded, tags from taglist are
added to the list of tags already applied to this module.

mod-to-sh [options] shell modulefile...
Evaluate modulefile and report resulting environment changes as code
for shell.

mod-to-sh command accepts the following options:

* --auto|--no-auto

* -f|--force

An attempt to load modulefile is made to get its environment
changes. This evaluation does not change the current shell environ-
ment. Like for load sub-command, no evaluation occurs if modulefile
is found loaded in current environment.

Changes made on environment variable intended for Modules private
use (e.g., LOADEDMODULES, _LMFILES_, __MODULES_*) are ignored.

Shell could be any shell name supported by modulecmd.tcl.

Produced shell code is returned on the message output channel by
modulecmd.tcl. Thus it is not rendered in current environment by the
module shell function.

mod-to-sh automatically set verbosity to the silent mode, to avoid
messages to mix with the produced shell code. Verbosity is not
changed if set to the trace mode or any higher debugging level.

When several modulefiles are passed, they are evaluated sequentially
in the specified order. If one modulefile evaluation raises an er-
ror, mod-to-sh sequence continues: environment change from modules
evaluated prior the error are preserved and sequence is resumed with
the evaluation of remaining modulefile in list. Conversely,
mod-to-sh sequence is aborted and changes from already evaluated
modules are withdrawn if mod-to-sh sub-command is defined in
abort_on_error configuration option and --force option is not set.

path modulefile
Print path to modulefile.

paths pattern
Print path of available modulefiles matching pattern.

The parameter pattern may also be a symbolic modulefile name or a
modulefile alias. It may also leverage a specific syntax to finely
select module version (see Advanced module version specifiers sec-
tion below).

prepend-path [options] variable value...
Prepend value to environment variable. The variable is a colon, or
delimiter, separated list. See prepend-path in the modulefile man
page for options description and further explanation.

When prepend-path is called as a module sub-command, the reference
counter variable, which denotes the number of times value has been
added to environment variable, is not updated unless if the --dupli-
cates option is set.

purge [-f]
Unload all loaded modulefiles.

When the --force option is set, also unload sticky modules, module-
files that are depended by non-unloadable modules and modulefiles
raising an evaluation error.

If one modulefile unload evaluation raises an error, purge sequence
continues: unloaded modules prior the evaluation error are kept un-
loaded and sequence is resumed with the unload of remaining module-
files. Conversely, purge sequence is aborted and already unloaded
modulefiles are restored if purge sub-command is defined in
abort_on_error configuration option and --force option is not set.

refresh
Force a refresh of all non-persistent components of currently loaded
modules. This should be used on derived shells where shell comple-
tions, shell aliases or shell functions need to be reinitialized but
the environment variables have already been set by the currently
loaded modules.

Loaded modules are evaluated in refresh mode following their load
order. In this evaluation mode only the complete, set-alias,
set-function and puts modulefile commands will produce environment
changes. Other modulefile commands that produce environment changes
(like setenv or append-path) are ignored during a refresh evaluation
as their changes should already be applied.

Only the loaded modules defining non-persistent environment changes
are evaluated in refresh mode. Such loaded modules are listed in the
__MODULES_LMREFRESH environment variable.

If one modulefile evaluation raises an error, refresh sequence con-
tinues: environment changes from refreshed modules prior the evalua-
tion error are preserved and sequence is resumed with the refresh of
remaining modulefiles.

reload [-f]
Unload then load all loaded modulefiles.

No unload then load is performed and an error is returned if the
loaded modulefiles have unsatisfied constraint corresponding to the
prereq and conflict they declare.

When the --force option is set, unload modulefiles anyway even if an
evaluation error occurs.

If one modulefile load or unload evaluation raises an error, reload
sequence aborts: environment changes coming from already evaluated
modulefiles are withdrawn and remaining modulefile evaluations are
skipped. Conversely, if reload is removed from abort_on_error con-
figuration option list or if --force option is set, reload sequence
continues: already achieved module evaluations are kept and reload
sequence is resumed with the remaining modulefiles.

remove-path [options] variable value...
Remove value from the colon, or delimiter, separated list in envi-
ronment variable. See remove-path in the modulefile man page for op-
tions description and further explanation.

When remove-path is called as a module sub-command, the reference
counter variable, which denotes the number of times value has been
added to environment variable, is ignored and value is removed what-
ever the reference counter value set.

reset [-f]
Restore initial environment, which corresponds to the loaded state
after Modules initialization.

reset sub-command restores the environment definition found in
__MODULES_LMINIT environment variable.

When the --force option is set, unload modulefiles anyway even if an
evaluation error occurs.

reset behavior can be changed with reset_target_state. This config-
uration option is set by default to __init__, which corresponds to
the above behavior description. When set to __purge__, reset per-
forms a purge of the environment. When set to any other value, reset
performs a restore of corresponding name collection.

restore [-f] [collection]
Restore the environment state as defined in collection. If collec-
tion name is not specified, then it is assumed to be the default
collection if it exists, __init__ special collection otherwise. If
collection is a fully qualified path, it is restored from this loca-
tion rather than from a file under the user's collection directory.
If MODULES_COLLECTION_TARGET is set, a suffix equivalent to the
value of this variable is appended to the collection file name to
restore.

If collection name is __init__, initial environment state defined in
__MODULES_LMINIT environment variable is restored.

When restoring a collection, the currently set MODULEPATH directory
list and the currently loaded modulefiles are unused and unloaded
then used and loaded to exactly match the MODULEPATH and loaded mod-
ulefiles lists saved in this collection file. The order of the paths
and modulefiles set in collection is preserved when restoring. It
means that currently loaded modules are unloaded to get the same
LOADEDMODULES root than collection and currently used module paths
are unused to get the same MODULEPATH root. Then missing module
paths are used and missing modulefiles are loaded.

If a module, without a default version explicitly defined, is
recorded in a collection by its bare name: loading this module when
restoring the collection will fail if the configuration option
implicit_default is disabled.

If one modulefile load or unload evaluation raises an error, restore
sequence continues: environment changes from modules unloaded or
loaded prior the evaluation error are preserved and sequence is re-
sumed with the unload or load of remaining modulefiles.

When the --force option is set, unload modulefiles anyway even if an
evaluation error occurs.

rm [--auto|--no-auto] [-f] modulefile...
See unload.

save [collection]
Record the currently set MODULEPATH directory list and the currently
loaded modulefiles in a collection file under the user's collection
directory $HOME/.module. If collection name is not specified, then
it is assumed to be the default collection. If collection is a fully
qualified path, it is saved at this location rather than under the
user's collection directory.

If MODULES_COLLECTION_TARGET is set, a suffix equivalent to the
value of this variable will be appended to the collection file name.

By default, if a loaded modulefile corresponds to the explicitly de-
fined default module version, the bare module name is recorded. If
the configuration option implicit_default is enabled, the bare mod-
ule name is also recorded for the implicit default module version.
If MODULES_COLLECTION_PIN_VERSION is set to 1, module version is al-
ways recorded even if it is the default version.

By default, only the module tags specifically set with the --tag op-
tion or resulting from a specific module state (like auto-loaded and
keep-loaded tags) are recorded in collection. If
MODULES_COLLECTION_PIN_TAG is set to 1, all tags are recorded in
collection except nearly-forbidden tag.

No collection is recorded and an error is returned if the loaded
modulefiles have unsatisfied constraint corresponding to the prereq
and conflict they declare.

savelist [-t|-l|-j] [-a] [-S|-C] [pattern...]
List collections that are currently saved under the user's collec-
tion directory. If MODULES_COLLECTION_TARGET is set, only collec-
tions matching the target suffix will be displayed unless if the
--all/-a option is set.

If a pattern is given, then the collections are filtered to only
list those whose name matches this pattern. It may contain wildcard
characters. pattern is matched in a case insensitive manner by de-
fault. If multiple patterns are given, collection has to match at
least one of them to be listed.

Stash collections are not listed unless if the --all/-a option is
set. Stash collections can be listed with stashlist sub-command.

saverm [collection]
Delete the collection file under the user's collection directory. If
collection name is not specified, then it is assumed to be the de-
fault collection. If MODULES_COLLECTION_TARGET is set, a suffix
equivalent to the value of this variable will be appended to the
collection file name.

saveshow [collection]
Display the content of collection. If collection name is not speci-
fied, then it is assumed to be the default collection if it exists,
__init__ special collection otherwise. If collection is a fully
qualified path, this location is displayed rather than a collection
file under the user's collection directory. If
MODULES_COLLECTION_TARGET is set, a suffix equivalent to the value
of this variable will be appended to the collection file name.

If collection name is __init__, initial environment content defined
in __MODULES_LMINIT environment variable is displayed.

search [-a] [-j] string
Seeks through the module-whatis information of all modulefiles for
the specified string. All module-whatis information matching the
string in a case insensitive manner will be displayed. string may
contain wildcard characters.

sh-to-mod shell script [arg...]
Evaluate with shell the designated script with defined arguments to
find out the environment changes it does. Environment prior and af-
ter script evaluation are compared to determine these changes. They
are translated into modulefile commands to output the modulefile
content equivalent to the evaluation of shell script.

Changes on environment variables, shell aliases, shell functions,
shell completions and current working directory are tracked.

Changes made on environment variable intended for Modules private
use (e.g., LOADEDMODULES, _LMFILES_, __MODULES_*) are ignored.

Shell could be specified as a command name or a fully qualified
pathname. The following shells are supported: sh, dash, csh, tcsh,
bash, ksh, ksh93, zsh and fish.

Shell could also be set to bash-eval. In this mode, bash shell
script is not sourced but the output resulting from its execution is
evaluated to determine the environment changes it does.

show modulefile...
See display.

source [options] modulefile...
Execute modulefile into the shell environment. Once executed module-
file is not marked loaded in shell environment which differ from
load sub-command.

source command accepts the following options:

* --auto|--no-auto

* -f|--force

If modulefile corresponds to a fully qualified path, this file is
executed. Otherwise modulefile is searched among the available mod-
ulefiles.

When several modulefiles are passed, they are evaluated sequentially
in the specified order. If one modulefile evaluation raises an er-
ror, source sequence continues: environment changes from modules
sourced prior the evaluation error are preserved and sequence is re-
sumed with the source of remaining modulefile in list.

spider sub-command first performs an Extra match search to get all
modulepaths to look at. These modulepaths are collected from the di-
rectory arguments set to the module use, append-path MODULEPATH or
prepend-path MODULEPATH modulefile commands. Collecting modulepaths
is first achieved in the global/user rc section and modulepaths de-
fined in MODULEPATH then in each modulepath collected from module-
files, and so on. As collecting modulepaths implies evaluating every
available modulefiles, it is advised to build and use Module cache
to improve search speed.

Once modulepaths are gathered, spider proceeds and reports like
avail sub-command. The same set of options are supported.

If a pattern argument is given, then each collected modulepath is
searched for modulefiles whose pathname, symbolic version-name or
alias match pattern in a case insensitive manner by default. pattern
may contain wildcard characters.i

Symbolic version-names and aliases found in the search are displayed
in the result of this sub-command. Symbolic version-names are dis-
played next to the modulefile they are assigned to within parenthe-
sis. Aliases are listed in the modulepath section where they have
been defined. To distinguish aliases from modulefiles a @ symbol is
added within parenthesis next to their name. Aliases defined through
a global or user specific module RC file are listed under the
global/user modulerc section.

Module tags applying to the available modulefiles returned by the
spider sub-command are reported along the module name they are asso-
ciated to (see Module tags section).

Module variants and their available values may be reported along the
module name they belong to (see Module variants section) if defined
in spider output configuration option (see --output/-o option). The
Extra match search process is triggered to collect variant informa-
tion.

When several patterns are provided all modulefiles matching at least
one of these patterns are listed.

stash [-f]
Save current environment in a stash collection then reset to initial
environment.

A collection is created only if current environment state differs
from initial environment. Stash collection is named stash-<unix_mil-
lis_timestamp> where <unix_millis_timestamp> is the number of mil-
liseconds between Unix Epoch and when this command is run.

If MODULES_COLLECTION_TARGET is set, a suffix equivalent to the
value of this variable will be appended to the stash collection file
name.

When the --force option is set, unload modulefiles anyway even if an
evaluation error occurs.

stashclear
Remove all stash collection files of current collection_target. If
no collection target is currently set, remove stash collection files
without a target suffix.

stashlist [-t|-l|-j]
List all stash collection files of current collection_target. If no
collection target is currently set, list stash collection files
without a target suffix.

stashpop [-f] [stash]
Restore stash collection then delete corresponding collection file.

stash is either a full stash collection name (i.e., stash-<unix_mil-
lis_timestamp>) or a stash index. Most recent stash collection has
index 0, 1 is the one before it. When no stash is given the latest
stash collection is assumed (that is stash index 0).

If MODULES_COLLECTION_TARGET is set, a suffix equivalent to the
value of this variable will be appended to the stash collection file
name to restore.

When the --force option is set, unload modulefiles anyway even if an
evaluation error occurs.

stashrm [stash]
Remove stash collection file.

If MODULES_COLLECTION_TARGET is set, a suffix equivalent to the
value of this variable will be appended to the stash collection file
name to delete.

stashshow [stash]
Display the content of stash collection file.

If MODULES_COLLECTION_TARGET is set, a suffix equivalent to the
value of this variable will be appended to the stash collection file
name to display.

state [name]
Gets modulecmd.tcl states. Reports the currently set value of passed
state name or all existing states if no name passed.

swap [options] [modulefile1] modulefile2
See switch.

switch [options] [modulefile1] modulefile2
Switch loaded modulefile1 with modulefile2. If modulefile1 is not
specified, it is assumed to be the currently loaded module that
shares the same root name as modulefile2. The root name is defined
as the initial part of a module name, i.e., all characters preceding
the first /.

switch command accepts the following options:

* --auto|--no-auto

* -f|--force

* --tag=taglist

The --tag option accepts a list of module tags to apply to module-
file once loaded. If module is already loaded, tags from taglist are
added to the list of tags already applied to this module.

When the --force option is set, unload modulefiles anyway even if an
evaluation error occurs.

If unload evaluation of modulefile1 raises an error, switch sequence
aborts: no environment change from modulefile1 unload is applied and
load of modulefile2 is skipped. Conversely, if switch_unload value
is removed from abort_on_error configuration option list (and switch
value is not set there) or if --force option is set, switch sequence
continues. If modulefile1 is tagged super-sticky, switch sequence
aborts in any case.

If load evaluation of modulefile2 raises an error, switch sequence
continues: environment changes from modulefile1 unload are applied
but not those from failed modulefile2 load. Conversely, whole switch
sequence is aborted and unloaded modulefile1 is restored if switch
sub-command is defined in abort_on_error configuration option and
--force option is not set.

test modulefile...
Execute and display results of the Module-specific tests for the
modulefile.

When several modulefiles are passed, they are evaluated sequentially
in the specified order. If one modulefile evaluation raises an er-
ror, test sequence continues.

try-add [options] modulefile...
See try-load.

try-load [options] modulefile...
Like load sub-command, load modulefile into the shell environment,
but do not complain if modulefile cannot be found. If modulefile is
found but its evaluation fails, error is still reported.

try-load command accepts the following options:

* --auto|--no-auto

* -f|--force

* --tag=taglist

The --tag option accepts a list of module tags to apply to module-
file once loaded. If module is already loaded, tags from taglist are
added to the list of tags already applied to this module.

When several modulefiles are passed, they are try-loaded sequen-
tially in the specified order. If one modulefile evaluation raises
an error, try-load sequence continues: loaded modules prior the
evaluation error are kept loaded and sequence is resumed with the
load of remaining modulefile in list. Conversely, try-load sequence
is aborted and already loaded modulefiles are withdrawn if try-load
sub-command is defined in abort_on_error configuration option and
--force option is not set.

unload [--auto|--no-auto] [-f] modulefile...
Remove modulefile from the shell environment.

When the --force option is set, unload modulefiles anyway even if an
evaluation error occurs.

When several modulefiles are passed, they are unloaded sequentially
in the specified order. If one modulefile evaluation raises an er-
ror, unload sequence continues: unloaded modules prior the evalua-
tion error are kept unloaded and sequence is resumed with the unload
of remaining modulefile in list. Conversely, unload sequence is
aborted and already unloaded modulefiles are restored if unload
sub-command is defined in abort_on_error configuration option and
--force option is not set.

unuse directory...
Remove one or more directories from the MODULEPATH environment vari-
able.

If module unuse is called during a modulefile evaluation, the refer-
ence counter environment variable __MODULES_SHARE_MODULEPATH, which
denotes the number of times directory has been enabled, is checked
and directory is removed only if its relative counter is equal to 1
or not defined. Otherwise directory is kept and reference counter
is decreased by 1. When module unuse is called from the command-line
or within an initialization modulefile script directory is removed
whatever the reference counter value set.

If directory corresponds to the concatenation of multiple paths sep-
arated by colon character, each path is treated separately.

update [-f]
See reload.

use [-a|--append] directory...
Prepend one or more directories to the MODULEPATH environment vari-
able. The --append flag will append the directory to MODULEPATH.

When directory is already defined in MODULEPATH, it is not added
again or moved at the end or at the beginning of the environment
variable.

If module use is called during a modulefile evaluation, the refer-
ence counter environment variable __MODULES_SHARE_MODULEPATH is also
set to increase the number of times directory has been added to
MODULEPATH. Reference counter is not updated when module use is
called from the command-line or within an initialization modulefile
script.

A directory that does not exist yet can be specified as argument and
then be added to MODULEPATH.

whatis [-a] [-j] [pattern...]
Display the information set up by the module-whatis commands inside
modulefiles matching pattern. pattern may contain wildcard charac-
ters. If no pattern is specified, all module-whatis lines will be
shown.

Modulefiles
modulefiles are written in the Tool Command Language (Tcl) and are inter-
preted by modulecmd.tcl. 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 envi-
ronment variables return to their prior state.

Advanced module version specifiers
When the advanced module version specifiers mechanism is enabled (see
MODULES_ADVANCED_VERSION_SPEC), the specification of modulefile passed on
Modules sub-commands changes. After the module name a version constraint
and variants may be added.

Version specifiers
After the module name a version constraint prefixed by the @ character may
be added. It could be directly appended to the module name or separated
from it with a space character.

Constraints can be expressed to refine the selection of module version to:

* a single version with the @version syntax, for instance foo@1.2.3 syntax
will select module foo/1.2.3

* a list of versions with the @version1,version2,... syntax, for instance
foo@1.2.3,1.10 will match modules foo/1.2.3 and foo/1.10

* a range of versions with the @version1:, @:version2 and @version1:ver-
sion2 syntaxes, for instance foo@1.2: will select all versions of module
foo greater than or equal to 1.2, foo@:1.3 will select all versions less
than or equal to 1.3 and foo@1.2:1.3 matches all versions between 1.2 and
1.3 including 1.2 and 1.3 versions

Advanced specification of single version or list of versions may benefit
from the activation of the extended default mechanism (see
MODULES_EXTENDED_DEFAULT) to use an abbreviated notation like @1 to refer
to more precise version numbers like 1.2.3. Range of versions on its side
natively handles abbreviated versions.

In order to be specified in a range of versions or compared to a range of
versions, the version major element should corresponds to a number. For in-
stance 10a, 1.2.3, 1.foo are versions valid for range comparison whereas
default or foo.2 versions are invalid for range comparison.

Range of versions can be specified in version list, for instance
foo@:1.2,1.4:1.6,1.8:. Such specification helps to exclude specific ver-
sions, like versions 1.3 and 1.7 in previous example.

If the implicit default mechanism is also enabled (see
MODULES_IMPLICIT_DEFAULT), a default and latest symbolic versions are auto-
matically defined for each module name (also at each directory level for
deep modulefiles). These automatic version symbols are defined unless a
symbolic version, alias, or regular module version already exists for these
default or latest version names. Using the mod@latest (or mod/latest) syn-
tax ensures highest available version will be selected.

The symbolic version loaded may be used over loaded module name to desig-
nate the loaded version of the module with associated selected variants.
This version symbol should be specified using the @ prefix notation (e.g.,
foo@loaded). An error is returned if no version of designated module is
currently loaded.

Variants
After the module name, variants can be specified. Module variants are al-
ternative evaluation of the same modulefile. A variant is specified by as-
sociating a value to its name. This specification is then transmitted to
the evaluating modulefile which instantiates the variant in the
ModuleVariant array variable when reaching the variant modulefile command
declaring this variant.

Variant can be specified with the name=value syntax where name is the de-
clared variant name and value, the value this variant is set to when evalu-
ating the modulefile.

Boolean variants can be specified with the +name syntax to set this variant
on and with the -name or ~name syntaxes to set this variant off. The -name
syntax is not supported on ml command as the minus sign already means to
unload designated module. The ~name and +name syntaxes could also be de-
fined appended to another specification word (e.g., the module name, ver-
sion or another variant specification), whereas -name syntax must be the
start of a new specification word.

Boolean variants may also be specified with the name=value syntax. value
should be set to 1, true, t, yes, y or on to enable the variant or it
should be set to 0, false, f, no, n or off to disable the variant.

Shortcuts may be used to abbreviate variant specification. The
variant_shortcut configuration option associates shortcut character to
variant name. With a shortcut defined, variant could be specified with the
<shortcut>value syntax. For instance if character % is set as a shortcut
for variant foo, the %value syntax is equivalent to the foo=value syntax.

A variant shortcut must be of one character length and must avoid charac-
ters used for other concerns or in module names or version specifications
(i.e., [-+~/@=:,a-zA-Z0-9]).

Variant name should only be composed of characters part of the A-Za-z0-9_-
range. Also, a variant name cannot start with - (minus) character and the
overall name cannot just be a number.

Specific characters used in variant specification syntax cannot be used as
part of the name or version of a module. These specific characters are +,
~, = and all characters set as variant shortcut. Exception is made for +
and ~ characters if string that follows after does not correspond to a
valid variant name (e.g., name+, name++, name/version+1).

Extra specifier
After the module name, extra specifiers can be defined in module search
context. Extra specifiers are an extra query to list available modulefiles
based on their content definition. They rely on the Extra match search
mechanism that collects content of available modulefiles.

Extra specifier can be set with the element:name[,name,...] syntax where
element is a Tcl modulefile command and name an item defined by this com-
mand. Depending on the kind of Tcl modulefile command, name can refer to an
environment variable, a shell alias, a module specification, etc.

Supported extra specifier elements are:

* variant, complete, uncomplete, set-alias, unset-alias, set-function, un-
set-function, chdir, tag

* setenv, unsetenv, append-path, prepend-path, remove-path and pushenv:
these elements related to environment variable handling may also be
aliased envvar

* family and provide: these elements related to module alias may also be
aliases provided-alias

* prereq, prereq-any, prereq-all, depends-on, depends-on-any, always-load,
load, load-any, try-load, switch and switch-on: these elements related to
module requirement definition accept a module specification as value name
and may be aliased require

* conflict, unload, switch and switch-off: these elements related to module
incompatibility definition accept a module specification as value name
and may be aliased incompat

* use

Each of the above supported elements corresponds to a Tcl modulefile com-
mand. load, load-any, try-load, switch, unload and use match corresponding
module sub-commands. prereq-any is an alias on prereq, depends-on-any and
vice versa as both Tcl modulefile commands are the same. Following the same
trend prereq-all is an alias on depends-on and vice versa. Regarding
switch-off and switch-on elements they correspond respectively to the mod-
ule to unload (if specified) and the module to load on a module switch com-
mand. switch is an alias that matches both switch-off and switch-on ele-
ments. require and incompat elements do not match module commands where
--not-req option is set. Setting the MODULEPATH environment variable with
append-path or prepend-path commands can be queried with use element.

When several names are set on one element criterion (e.g., env:PATH,LD_LI-
BRARY_PATH), they act as an OR operation. Which means modules listed in re-
sult are those matching any of the element names defined.

When several extra specifiers are set on a module search query (e.g.,
env:PATH env:LD_LIBRARY_PATH), they act as an AND operation. Which means
modules listed in result are those matching all extra specifiers defined.

When an extra specifier is prefixed by not: (e.g., not:env:PATH), it acts
as a NOT operation. Which means modules listed in result are those not
matching the extra specifier defined.

Module specification used as name value for some extra specifier elements
may leverage Advanced module version specifiers syntax. However if a module
version range or list is implied, it is currently resolved to existing mod-
ules. Thus it may not match modulefile definitions targeting modules that
do not exist. In addition, module aliases and symbolic versions are not re-
solved to their target either if set in extra specifier query or in module-
file definition.

Extra specifier can only be set in a module search context (avail, spider,
whatis and paths sub-commands). An error is raised if used on a module
specification query in another context. An error is also raised if an un-
known extra specifier element is defined in search query.

Module tags
Module tags are piece of information that can be associated to individual
modulefiles. Tags could be purely informational or may lead to specific be-
haviors.

Module tags may be inherited from the module state set by a modulefile com-
mand or consequence of a module action. The inherited tags are:

* auto-loaded: module has been automatically loaded by another module

* forbidden: module has been set forbidden through the use of the
module-forbid command and thus this module cannot be loaded.

* hidden: module has been set hidden through the use of the module-hide
command and thus it is not reported by default among the result of avail
or spider sub-commands.

* hidden-loaded: module has been set hidden once loaded through the use of
the module-hide --hidden-loaded command thus it is not reported by de-
fault among the result of a list sub-command.

* loaded: module is currently loaded

* nearly-forbidden: module will soon be forbidden, which has been set
through the use of the module-forbid command. Thus this module will soon
not be able to load anymore.

* warning: a warning message for the use of the module is set through the
use of the module-warn command.

Tags may also be associated to modules by using the module-tag modulefile
command. Among tags that could be set this way, some have a special mean-
ing:

* keep-loaded: auto-loaded module cannot be automatically unloaded. This
tag is also set through the use of the always-load command.

* sticky: module once loaded cannot be unloaded unless forced or reloaded
(see Sticky modules section)

* super-sticky: module once loaded cannot be unloaded unless reloaded, mod-
ule cannot be unloaded even if forced (see Sticky modules section)

The --tag option helps to apply additional tags to modules. It is available
on load, load-any, switch and try-load sub-commands and on always-load,
depends-on, depends-on-any, module, prereq, prereq-all and prereq-any mod-
ulefile commands. In case the designated module is already loaded, the ad-
ditional tags are added to the list of tags already applied to this module.

Module tags are reported along the module they are associated to on avail,
list and spider sub-command results and also when module's loading, unload-
ing, refreshing or tagging evaluation is mentioned. Tags could be reported
either:

* along the module name, all tags set within angle brackets, each tag sepa-
rated from the others with a colon character (e.g., foo/1.2 <tag1:tag2>).

* graphically rendered over the module name for each tag associated to a
Select Graphic Rendition (SGR) code in the color palette (see
MODULES_COLORS)

When an abbreviated string is associated to a tag name (see
MODULES_TAG_ABBREV), this abbreviation is used to report tag along the mod-
ule name or the tag is graphically rendered over the module name if a SGR
code is associated with tag abbreviation in the color palette. With an ab-
breviation set, the SGR code associated to the tag full name is ignored
thus an SGR code should be associated to the abbreviation to get a graphi-
cal rendering of tag. If the abbreviation associated to a tag corresponds
to the empty string, tag is not reported.

Graphical rendering is made over the tag name or abbreviation instead of
over the module name for each tag name or abbreviation set in the
MODULES_TAG_COLOR_NAME environment variable.

When several tags have to be rendered graphically over the same module
name, each tag is rendered over a sub-part of the module name. In case more
tags need to be rendered than the total number of characters in the module
name, the remaining tags are graphically rendered over the tag name instead
of over the module name.

When the JSON output mode is enabled (with --json), tags are reported by
their name under the tags attribute. Tag abbreviation and color rendering
do not apply on JSON output.

Module tags cannot be used in search query to designate a modulefile.

Sticky modules
Modules are said sticky when they cannot be unloaded (they stick to the
loaded environment). Two kind of stickiness can be distinguished:

* sticky module: cannot be unloaded unless if the unload is forced or if
the module is reloaded after being unloaded or if restoring a collection.

* super-sticky module: cannot be unloaded unless if the module is reloaded
after being unloaded; super-sticky modules cannot be unloaded even if the
unload is forced.

Modules are designated sticky by associating them the sticky or the su-
per-sticky module tag with the module-tag modulefile command.

When stickiness is defined over the generic module name (and not over a
specific module version, a version list or a version range), sticky or su-
per-sticky module can be swapped by another version of module. For instance
if the sticky tag is defined over foo module, loaded module foo/1.2 can be
swapped by foo/2.0. Such stickiness definition means one version of module
should stay loaded whatever version it is.

When restoring a collection or resetting to the initial environment, sticky
modules are unloaded to ensure restore or reset sub-commands fully set the
environment in target collection or initial state. Super-sticky modules
still cannot be unloaded with restore and reset sub-commands.

Module variants
Module variants are alternative evaluation of the same modulefile. A vari-
ant is specified by associating a value to its name when designating mod-
ule. Variant specification relies on the Advanced module version speci-
fiers mechanism.

Once specified, variant's value is transmitted to the evaluating modulefile
which instantiates the variant in the ModuleVariant array variable when
reaching the variant modulefile command declaring this variant. For in-
stance the module load foo/1.2 bar=value1 command leads to the evaluation
of foo/1.2 modulefile with bar=value1 variant specification. When reaching
the variant bar value1 value2 value3 command in modulefile during its eval-
uation, the ModuleVariant(bar) array element is set to the value1 string.

Once variants are instantiated, modulefile's code could check the variant
values to adapt the evaluation and define for instance different module re-
quirements or produce different environment variable setup.

Variants are interpreted in contexts where modulefiles are evaluated.
Variants specified on module designation are ignored by the is-avail or
path sub-commands. On search sub-commands (avail, spider, whatis and
paths), variants are interpreted and trigger the Extra match search process
to filter results.

When modulefile is evaluated a value should be specified for each variant
this modulefile declares. When reaching the variant modulefile command de-
claring a variant, an error is raised if no value is specified for this
variant and if no default value is declared. Specified variant value should
match a value from the declared accepted value list if such list is defined
otherwise an error is raised. Additionally if a variant is specified but
does not correspond to a variant declared in modulefile, an error is
raised.

When searching for modules with variants specified in search query, the
Extra match search process triggers a specific scan modulefile evaluation.
Variants defined in modulefile are collected during this evaluation then
compared to the variants specified in search query. If there is a match,
module is included in search results otherwise it is withdrawn.

When searching for available modules, if one variant is specified multiple
times, matching modules are those providing all specified variant values.
For instance bar=value1 bar=value2 will return modules defining a bar vari-
ant with value1 and value2 as available values. On a module selection con-
text, only the last specified value is retained. Which means on previous
example that bar variant is set to value2.

When searching for available modules, multiple values may be set on one
variant criterion, which matches modules that provide any of these variant
values. For instance bar=value1,value2 will return modules defining a bar
variant with either value1 or value2 as available value.

When searching for available modules, not: prefix may be added on variant
criterion, which matches modules that do not provide these variant values.
For instance not:bar=value1 will return modules not defining a bar variant
or defining a bar variant but without value1 among available values.

Module variants are reported along the module they are associated to on
list sub-command results. They are also reported on avail and spider
sub-commands if specified in search query or added to the element to report
in sub-command output (see --output/-o option).

Variants are reported within curly braces next to module name, each variant
definition separated from the others with a colon character (e.g.,
foo/1.2{variant1=value:+variant2}). Boolean variants are reported with the
+name or -name syntaxes on list sub-command or with the name=on,off syntax
on avail and spider sub-commands. When a shortcut character is defined for
a variant (see MODULES_VARIANT_SHORTCUT) it is reported with the <short-
cut>value syntax. For instance if % character is defined as a shortcut for
variant1: foo/1.2{%value:+variant2}.

When the JSON output mode is enabled (with --json), variants are reported
under the variants JSON object as name/value pairs. Values of Boolean vari-
ant are set as JSON Boolean. Other values are set as JSON strings. Variant
shortcut and color rendering do not apply on JSON output.

Extra match search
Extra match search is a mechanism that evaluates available modulefiles dur-
ing a module search to find those matching an extra query or to report ad-
ditional information. After selecting modulefiles that match the module
name and version specified in search query, these remaining modulefiles are
evaluated to collect their content.

Extra match search is available on the following module search sub-com-
mands: avail, spider, whatis and paths.

Extra match search is triggered when:

* Module variants and their available values have to be reported in avail
and spider outputs (see --output/-o option): extra match search is trig-
gered to collect variant information

* Provided module aliases have to be reported in avail and spider outputs
(see --output/-o option): extra match search is triggered to collect
these module aliases defined within modulefiles

* Module variant is specified in search query: extra match search is trig-
gered to collect variant information then match them against variant
specified in query

* Extra specifier is specified in search query: extra match search is trig-
gered to collect commands used in modulefiles or modulercs then match
them against extra specifier query

If search query does not contain an extra query and if variant or provided
alias information should not be reported, no extra match search is per-
formed. If search query does not contain any module name and version but
contains an extra query or if variant information should be reported, extra
match search is applied to all available modulefiles. If provided alias in-
formation should be reported, extra match search is applied to all avail-
able modulefiles even if search query contains a module specification.

During this specific evaluation, modulefiles are interpreted in scan mode.
This mode aims to collect the different Tcl modulefile commands used. Spe-
cial care should be given when writing modulefiles to ensure they cope with
such evaluation mode.

Modulefiles tagged forbidden are excluded from extra match search evalua-
tion. Thus they are excluded from result when this mechanism is triggered.

No scan modulefile evaluation is performed if search query is only composed
of tag extra specifier. Module tags are defined in modulercs thus no mod-
ulefile evaluation is required to get tags applying to a modulefile.

As extra match search implies additional modulefile evaluations, it is ad-
vised to build and use Module cache to improve search speed.

Collections
Collections describe a sequence of module use then module load commands
that are interpreted by modulecmd.tcl to set the user environment as de-
scribed by this sequence.

Collections are generated by the save sub-command that dumps the current
user environment state in terms of module paths and loaded modules. By de-
fault collections are saved under the $HOME/.module directory.

$ module list
Currently Loaded Modulefiles:
1) foo/1.2 2) bar/2.0 3) qux/3.5
$ module save foo
$ cat $HOME/.module/foo
module use --append /path/to/modulefiles
module load foo
module load bar/2.0
module load qux/3.5

The content of a collection can also be displayed with the saveshow
sub-command. Note that in the above example, bare module name is recorded
for foo modulefile as loaded version is the implicit default. Loaded ver-
sion recording can be enforced by enabling collection_pin_version configu-
ration option.

$ module config collection_pin_version 1
$ module save foo
$ module saveshow foo
-------------------------------------------------------------------
/home/user/.module/foo:

module use --append /path/to/modulefiles
module load foo/1.2
module load bar/2.0
module load qux/3.5

-------------------------------------------------------------------

When a collection is activated, with the restore sub-command, module paths
and loaded modules are unused or unloaded if they are not part or if they
are not ordered the same way as in the collection.

$ module list
Currently Loaded Modulefiles:
1) foo/1.2 2) bar/2.1 3) qux/3.5
$ module restore foo
Unloading qux/3.5
Unloading bar/2.1
Loading bar/2.0
Loading qux/3.5
$ module list
Currently Loaded Modulefiles:
1) foo/1.2 2) bar/2.0 3) qux/3.5

In the above example, second and third module loaded are changed. First
loaded module is not changed or reloaded as it is the same module between
current environment and collection. As second loaded module was different,
this module and all those loaded afterward are unloaded to then load the
sequence described by collection. As a result, third loaded module is re-
loaded, even if is was the same module between current environment and col-
lection.

Existing collections can be listed with savelist sub-command. They can be
deleted with saverm sub-command.

$ module savelist
Named collection list:
1) default 2) foo
$ module saverm default
$ module savelist
Named collection list:
1) foo

When no argument is provided to save, restore, saveshow or saverm sub-com-
mands, the default collection is assumed.

Collection can also be specified as a full pathname:

$ module save /path/to/collections/bar
$ module saveshow /path/to/collections/bar
-------------------------------------------------------------------
/path/to/collections/bar:

module use --append /path/to/modulefiles
module load foo/1.2
module load bar/2.0
module load qux/3.5

-------------------------------------------------------------------

Initial environment
Initial environment state, which corresponds to modulepaths enabled and
modules loaded during Modules initialization, is referred as the __init__
collection. This collection is virtual as its content is stored in the
__MODULES_LMINIT and not in a file. It can be displayed with saveshow and
restored with restore sub-command.

$ module saveshow __init__
-------------------------------------------------------------------
initial environment:

module use --append /path/to/modulefiles
module load foo/1.2

-------------------------------------------------------------------

If the default collection does not exist, saveshow and restore sub-commands
assume __init__ collection when no argument provided to them.

$ module list
Currently Loaded Modulefiles:
1) foo/1.2 2) bar/2.1 3) qux/3.5
$ module savelist
Named collection list:
1) foo
$ module restore
Unloading qux/3.5
Unloading bar/2.1

Initial environment state can also be restored with the reset sub-command.
This sub-command behavior can be changed with reset_target_state configura-
tion option to choose to just purge loaded modules or to restore a specific
collection.

Collection targets
A collection target can be defined for current environment session with the
collection_target configuration option. When set, available collections are
reduced to those suffixed with target name. Which means restore, saveshow,
savelist and saverm only find collections matching currently set target.

$ module savelist
Named collection list:
1) foo
$ module config collection_target mytarget
$ module savelist
No named collection (for target "mytarget").
$ module restore foo
ERROR: Collection foo (for target "mytarget") cannot be found

When saving a new collection, generated file is suffixed with currently set
target name.

$ module save bar
$ module savelist
Named collection list (for target "mytarget"):
1) bar
$ ls $HOME/.module
bar.mytarget foo

Collection targets help to distinguish contexts and make collection reach-
able only from the context they have been made for. For instance the same
user account may be used to access different OSes or machine architectures.
With a target set, users are ensured to only access collections built for
the context they are currently connected to. See also
MODULES_COLLECTION_TARGET section.

Stash collections
Current user environment can be stashed with stash sub-command. When this
sub-command is called, current module environment is saved in a stash col-
lection then initial environment is restored.

$ module list
Currently Loaded Modulefiles:
1) foo/1.2 2) qux/4.2
$ module stash
Unloading qux/4.2

Specific sub-commands are available to handle stash collections: stashpop,
stashlist, stashshow, stashrm and stashclear. A stash collection is re-
stored with stashpop which also deletes the collection once restored.

$ module stashlist
Stash collection list (for target "mytarget"):
0) stash-1667669750191
$ module stashpop
Loading qux/4.2
$ module stashlist
No stash collection (for target "mytarget").

Stash collections have same format and are saved in the same location than
other collections. Collection target also applies to stash collection.
Creation timestamp is saved in stash collection name.

Stash collection can be designated by their full collection name (i.e.,
stash-<creation_timestamp>) or a stash index. Most recent stash collection
has index 0, 1 is the one before it. When no argument is provided on stash
sub-commands, the latest stash collection is assumed (that is stash index
0).

$ module stashlist
Stash collection list (for target "mytarget"):
0) stash-1667669750783 1) stash-1667669750253
$ module stashshow 1
-------------------------------------------------------------------
/home/user/.module/stash-1667669750253.mytarget:

module use --append /path/to/modulefiles
module load foo/1.2
module load bar/2.0

-------------------------------------------------------------------

Site-specific configuration
Siteconfig, the site-specific configuration script, is a way to extend mod-
ulecmd.tcl. Siteconfig is a Tcl script. Its location is /usr/local/Mod-
ules/5.6.1/etc/siteconfig.tcl.

When modulecmd.tcl is invoked it sources siteconfig script if it exists.
Any global variable or procedure of modulecmd.tcl can be redefined in site-
config.

An additional siteconfig script may be specified through the
extra_siteconfig configuration option. The MODULES_SITECONFIG environment
variable is defined by config sub-command when setting extra_siteconfig. If
it exists the extra siteconfig is sourced by modulecmd.tcl right after main
siteconfig script.

Hooks
Siteconfig relies on the ability of the Tcl language to overwrite previ-
ously defined variables and procedures. Sites may deploy their own Tcl code
in siteconfig to adapt modulecmd.tcl to their specific needs. The trace Tcl
command may especially be used to define hooks that are run when entering
or leaving a given procedure, or when a variable is read or written. See
trace(n) man page for detailed information. The following example setup a
procedure that is executed before each modulefile evaluation:

proc beforeEval {cmdstring code result op} {
# code to run right before each modulefile evaluation
}
trace add execution execute-modulefile enter beforeEval

Another possibility is to override the definition of an existing procedure
by first renaming its original version then creating a new procedure that
will add specific code and rely on the renamed original procedure for the
rest. See rename(n) man page for details. As an example, the following code
adds a new query option to the module-info modulefile command:

rename module-info __module-info
proc module-info {what {more {}}} {
switch -- $what {
platform { return myhost-$::tcl_platform(machine) }
default { return [__module-info $what $more] }
}
}

If a hook procedure needs to execute modulefile commands (for example, to
define environment variables), these commands should be run through the
current modulefile Tcl interpreter. This ensures that the commands behave
consistently with the current modulefile evaluation mode.

proc hook_procedure {value} {
# get the name of the current modulefile Tcl interpreter
set modfile_interp [getCurrentModfileInterpName]

# execute a modulefile command in the current interpreter context
interp eval $modfile_interp setenv MYVAR $value
}

Siteconfig hook variables
Some Tcl variables can be defined in siteconfig script with special hook
meaning. The following variables are recognized:

modulefile_extra_vars
List of variable names and associated values to setup in modulefile
evaluation context. These variables can be accessed when modulefile
is executed. In case code in a modulefile changes the value of such
variable, its value is reset to the one defined in
modulefile_extra_vars prior the evaluation of the next modulefile.

set modulefile_extra_vars {myvar 1 othervar {some text}}

In the above siteconfig example, modulefile_extra_vars sets the my-
var and othervar variables in the modulefile evaluation context with
respectively 1 and some text as value.

modulefile_extra_cmds
List of command and associated local procedure to setup in module-
file evaluation context. These commands can be called from the mod-
ulefile to execute associated procedure. In case a modulefile
changes the definition of such command, its definition is bound
again on the procedure defined in modulefile_extra_cmds prior the
evaluation of the next modulefile.

proc mycmd {} {
# Tcl code
}
proc anotherproc {args} {
# Tcl code
}
set modulefile_extra_cmds {mycmd mycmd othercmd anotherproc}

In the above siteconfig example, modulefile_extra_cmds sets the my-
cmd and othercmd commands in the modulefile evaluation context and
bind them respectively to the mycmd and anotherproc procedures de-
fined in siteconfig script.

modulerc_extra_vars
List of variable names and associated values to setup in modulerc
evaluation context. These variables can be accessed when modulerc is
executed. In case code in a modulerc changes the value of such vari-
able, its value is reset to the one defined in modulerc_extra_vars
prior the evaluation of the next modulerc.

set modulerc_extra_vars {myvar 1 othervar {some text}}

In the above siteconfig example, modulerc_extra_vars sets the myvar
and othervar variables in the modulerc evaluation context with re-
spectively 1 and some text as value.

modulerc_extra_cmds
List of command and associated local procedure to setup in modulerc
evaluation context. These commands can be called from the modulerc
to execute associated procedure. In case a modulerc changes the def-
inition of such command, its definition is bound again on the proce-
dure defined in modulerc_extra_cmds prior the evaluation of the next
modulerc.

proc mycmd {} {
# Tcl code
}
proc anotherproc {args} {
# Tcl code
}
set modulerc_extra_cmds {mycmd mycmd othercmd anotherproc}

In the above siteconfig example, modulerc_extra_cmds sets the mycmd
and othercmd commands in the modulerc evaluation context and bind
them respectively to the mycmd and anotherproc procedures defined in
siteconfig script.

Module cache
To improve module search efficiency, a module cache can be setup in each
modulepath. A module cache is represented by a .modulecache file stored at
the root of modulepath directory. This file aggregates contents of all
valid modulercs and modulefiles and issue description of all non-module-
files stored in modulepath directory.

When cache file is available, a module search analyzes this file rather
walking through the content of modulepath directory to check if files are
modulefiles or not. Cache file reduces module search processing time espe-
cially when hundreds of modulefiles are available and if these files are
located on busy storage systems. Having one file to read per modulepath
rather walking through a whole directory content extremely reduces the num-
ber of required I/O operations.

When modulefiles or directories in the modulepath are not accessible for
everyone, a limited access indication is recorded in cache file rather con-
tent of these modulefiles and content of these directories. When cache file
containing such indication is processed, the limited access modulefiles are
tested to check if they are available to the current running user. Limited
access directories are walked down to find all available modulefiles and
modulercs.

Cache files are generated with cachebuild sub-command. This command has to
be run by someone who owns write access in modulepath directory to create
cache file.

Cache files are used any time a module search occurs in modulepaths. They
are analyzed for instance during avail, spider, load, display or whatis
sub-commands.

Cache files are removed with cacheclear sub-command. This command has to be
run by someone who own write access in modulepath directory to effectively
delete cache file.

EXIT STATUS
The module command exits with 0 if its execution succeed. Otherwise 1 is
returned.

ENVIRONMENT
__MODULES_AUTOINIT_INPROGRESS
If set to 1, the autoinit sub-command process is skipped.

This environment variable is set to 1 by the autoinit sub-command
after checking it is not set. It ensures no nested initialization of
Modules occur. At the end of the processing of the autoinit sub-com-
mand, __MODULES_AUTOINIT_INPROGRESS is unset.

__MODULES_LMALTNAME
A colon separated list of the alternative names set through
module-version and module-alias statements corresponding to all
loaded modulefiles. Each element in this list starts by the name of
the loaded modulefile followed by all alternative names resolving to
it. The loaded modulefile and its alternative names are separated by
the ampersand character.

Each alternative name stored in __MODULES_LMALTNAME is prefixed by
the al| string if it corresponds to a module alias or prefixed by
the as| string if it corresponds to an automatic version symbol.
These prefixes help to distinguish the different kind of alternative
name.

This environment variable is intended for module command internal
use to get knowledge of the alternative names matching loaded mod-
ulefiles in order to keep environment consistent when conflicts or
pre-requirements are set over these alternative designations. It
also helps to find a match after modulefiles being loaded when
unload, is-loaded or info-loaded actions are run over these names.

Starting version 4.7 of Modules, __MODULES_LMALTNAME is also used on
list sub-command to report the symbolic versions associated with the
loaded modules.

__MODULES_LMCONFLICT
A colon separated list of the conflict statements defined by all
loaded modulefiles. Each element in this list starts by the name of
the loaded modulefile declaring the conflict followed by the name of
all modulefiles it declares a conflict with. These loaded module-
files and conflicting modulefile names are separated by the amper-
sand character.

This environment variable is intended for module command internal
use to get knowledge of the conflicts declared by the loaded module-
files in order to keep environment consistent when a conflicting
module is asked for load afterward.

__MODULES_LMEXTRATAG
A colon separated list of the tags corresponding to all loaded mod-
ulefiles that have been set through the --tag option. Each element
in this list starts by the name of the loaded modulefile followed by
all explicitly set tags applying to it. The loaded modulefile and
its tags are separated by the ampersand character.

This environment variable is intended for module command internal
use to distinguish from all tags those that have been specifically
set with --tag option.

__MODULES_LMINIT
A colon separated list describing the modulepaths that have been en-
abled and the modulefiles that have been loaded with their tags dur-
ing Modules initialization. Each element in this list corresponds to
a collection definition line.

This environment variable is intended for module command internal
use to get knowledge of the initial loaded state after initializa-
tion.

This initial environment state can then be restored with reset
sub-command. It can also be restored with restore sub-command when
__init__ collection name is specified or when no collection name is
specified and no default collection exists.

The content of the initial environment can be displayed with
saveshow sub-command when __init__ collection name is specified or
when no collection name is specified and no default collection ex-
ists.

__MODULES_LMPREREQ
A colon separated list of the prereq statements defined by all
loaded modulefiles. Each element in this list starts by the name of
the loaded modulefile declaring the pre-requirement followed by the
name of all modulefiles it declares a prereq with. These loaded mod-
ulefiles and pre-required modulefile names are separated by the am-
persand character. When a prereq statement is composed of multiple
modulefiles, these modulefile names are separated by the pipe char-
acter.

This environment variable is intended for module command internal
use to get knowledge of the pre-requirement declared by the loaded
modulefiles in order to keep environment consistent when a pre-re-
quired module is asked for unload afterward.

__MODULES_LMPREREQPATH
A colon separated list of the prereq statements set with a specific
--modulepath option defined by all loaded modulefiles. Each element
in this list starts by the name of the loaded modulefile declaring
the pre-requirement followed by the name of all modulefiles it de-
clares a prereq with and their specific modulepath. These loaded
modulefiles, pre-required modulefile names and specific modulepaths
set are separated by the ampersand character. When a prereq state-
ment is composed of multiple modulefiles or multiple specific mod-
ulepaths, these names are separated by the pipe character.

This environment variable is intended for module command internal
use to get knowledge of the pre-requirement declared by the loaded
modulefiles in order to keep environment consistent.

__MODULES_LMREFRESH
A colon separated list of the loaded modules that are qualified for
refresh evaluation. Loaded modules listed in this variable are those
defining volatile environment changes like shell completion, alias
and function.

__MODULES_LMSOURCESH
A colon separated list of the source-sh statements defined by all
loaded modulefiles. Each element in this list starts by the name of
the loaded modulefile declaring the environment changes made by the
evaluation of source-sh scripts. This name is followed by each
source-sh statement call and corresponding result achieved in mod-
ulefile. The loaded modulefile name and each source-sh statement de-
scription are separated by the ampersand character. The source-sh
statement call and each resulting modulefile command (corresponding
to the environment changes done by sourced script) are separated by
the pipe character.

This environment variable is intended for module command internal
use to get knowledge of the modulefile commands applied for each
source-sh command when loading the modulefile. In order to reverse
these modulefile commands when modulefile is unloaded to undo the
environment changes.

__MODULES_LMSTICKYRULE
A colon separated list of the sticky or super-sticky tag definitions
applying to loaded modulefiles. Each element in this list starts by
the name of the loaded modulefile followed by the sticky tag name
and the module specifications on which the tag applies. These loaded
modulefiles and sticky tag definitions are separated by the amper-
sand character. Tag name and module specifications on which it ap-
plies are separated by the pipe character.

When stickiness applies specifically to the loaded module name and
version, sticky rule is not recorded in __MODULES_LMSTICKYRULE.

This environment variable is intended for module command internal
use to get knowledge of the stickiness scope when sticky module is
changed.

__MODULES_LMTAG
A colon separated list of the tags corresponding to all loaded mod-
ulefiles that have been set through module-tag statements or from
other modulefile statements like module-forbid (that may apply the
nearly-forbidden tag in specific situation) (see Module tags sec-
tion). Each element in this list starts by the name of the loaded
modulefile followed by all tags applying to it. The loaded module-
file and its tags are separated by the ampersand character.

This environment variable is intended for module command internal
use to get knowledge of the tags applying to loaded modulefiles in
order to report these tags on list sub-command output or to apply
specific behavior when unloading modulefile.

__MODULES_LMUSE
A colon separated list of the modulepaths enabled by all loaded mod-
ulefiles. Each element in this list starts by the name of the loaded
modulefile enabling modulepath followed by all modulepaths it en-
ables. These loaded modulefiles and enabled modulepaths are sepa-
rated by the ampersand character.

This environment variable is intended for module command internal
use to get knowledge of the modulepath enabled by the loaded module-
files in order to keep environment consistent when unloading these
modules whereas modulefiles from the enabled modulepaths are loaded.

__MODULES_LMVARIANT
A colon separated list of the variant instantiated through variant
statements by all loaded modulefiles (see Module variants section).
Each element in this list starts by the name of the loaded module-
file followed by all the variant definitions set during the load of
this module. The loaded modulefile and each of its variant defini-
tion are separated by the ampersand character. Each variant defini-
tion starts with the variant name, followed by the variant value
set, then a flag to know if variant is of the Boolean type and last
element in this definition is a flag to know if the chosen value is
the default one for this variant and if it has been automatically
set or not. These four elements composing the variant definition are
separated by the pipe character.

This environment variable is intended for module command internal
use to get knowledge of the variant value defined by the loaded mod-
ulefiles in order to keep environment consistent when requirements
are set over a specific variant value or just to report these vari-
ant values when listing loaded modules.

__MODULES_PUSHENV_<VAR>
Stack of saved values for <VAR> environment variable. A colon-sepa-
rated list containing pairs of elements. A pair is formed by a
loaded module name followed by the value set to <VAR> in this module
with pushenv command. An ampersand character separates the two parts
of the pair.

First element in list corresponds to the lastly set value of <VAR>.
If a value were set to <VAR> prior the first evaluated pushenv com-
mand, this value is associated to an empty module name to record it
as a pair element in __MODULES_PUSHENV_<VAR>.

__MODULES_QUAR_<VAR>
Value of environment variable <VAR> passed to modulecmd.tcl in order
to restore <VAR> to this value once started.

__MODULES_QUARANTINE_SET
If set to 1, restore the environment variables set on hold by the
quarantine mechanism when starting modulecmd.tcl script. This vari-
able is automatically defined by Modules shell initialization
scripts or module shell function when they apply the quarantine
mechanism. (see MODULES_QUARANTINE_SUPPORT).

__MODULES_SHARE_<VAR>
Reference counter variable for path-like variable <VAR>. A colon
separated list containing pairs of elements. A pair is formed by a
path element followed its usage counter which represents the number
of times this path has been enabled in variable <VAR>. A colon sepa-
rates the two parts of the pair.

An element of a path-like variable is added to the reference counter
variable as soon as it is added more than one time. When an element
of a path-like variable is not found in the reference counter vari-
able, it means this element has only be added once to the path-like
variable.

When an empty string is added as an element in the path-like vari-
able, it is added to the reference counter variable even if added
only once to distinguish between an empty path-like variable and a
path-like variable containing an empty string as single element.

_LMFILES_
A colon separated list of the full pathname for all loaded module-
files.

This environment variable is generated by module command and should
not be modified externally.

LOADEDMODULES
A colon separated list of all loaded modulefiles.

This environment variable is generated by module command and should
not be modified externally.

MODULECONTACT
Email address to contact in case any issue occurs during the inter-
pretation of modulefiles.

This environment variable value supersedes the default value set in
the contact configuration option. It can be defined with the config
sub-command.

MODULEPATH
The path that the module command searches when looking for module-
files. Typically, it is set to the main modulefiles directory,
/usr/local/Modules/5.6.1/modulefiles, by the initialization script.
MODULEPATH can be set using module use or by the module initializa-
tion script to search group or personal modulefile directories be-
fore or after the main modulefile directory.

Path elements registered in the MODULEPATH environment variable may
contain reference to environment variables which are converted to
their corresponding value by module command each time it looks at
the MODULEPATH value. If an environment variable referred in a path
element is not defined, its reference is converted to an empty
string.

MODULERCFILE
The location of a global run-command file(s) containing modulefile
specific setup. See Modulecmd startup section for detailed informa-
tion.

Several global run-command files may be defined in this environment
variable by separating each of them by colon character.

This environment variable value supersedes the default value set in
the rcfile configuration option. It can be defined with the config
sub-command.

MODULES_ABORT_ON_ERROR
A colon separated list of the module sub-commands that abort their
evaluation sequence when an error is raised by an evaluated module.
When error occurs, evaluations already done are withdrawn and the
remaining modules to evaluate are skipped.

Accepted sub-commands that can be set in value list are:

* load

* ml

* mod-to-sh

* purge

* reload

* switch

* switch_unload

* try-load

* unload

Module sub-commands not configured to follow the abort on error be-
havior, apply the continue on error behavior. In this case if one
modulefile evaluation fails, sequence continues with remaining mod-
ulefiles. When --force option is used, continue on error behavior
applies.

This environment variable value supersedes the default value set in
the abort_on_error configuration option. It can be defined with the
config sub-command.

MODULES_ADVANCED_VERSION_SPEC
If set to 1, enable advanced module version specifiers (see Advanced
module version specifiers section). If set to 0, disable advanced
module version specifiers.

This environment variable value supersedes the default value set in
the advanced_version_spec configuration option. It can be defined
with the config sub-command.

MODULES_AUTO_HANDLING
If set to 1, enable automated module handling mode. If set to 0 dis-
able automated module handling mode. Other values are ignored.

Automated module handling mode consists in additional actions trig-
gered when loading or unloading a modulefile to satisfy the con-
straints it declares. When loading a modulefile, following actions
are triggered:

* Conflict Unload: unload of the modulefiles declared as a conflict
of the loading modulefile or if it is the same modulefile than the
one loading but with a different set of variant or coming from a
different modulepath.

* Requirement Load: load of the modulefiles declared as a prereq of
the loading modulefile.

* Useless Requirement Unload: unload of the prereq modulefiles that
have been automatically loaded for either an unloaded conflicting
modulefile or a modulefile part of this useless requirement un-
loading batch. Modulefiles are added to this unloading batch only
if they are not required by any other loaded modulefiles and if
they are not tagged keep-loaded, sticky or super-sticky.

* Dependent Reload: reload of the modulefiles declaring a prereq
onto loading modulefile or declaring a prereq or a via requirement
onto a modulefile part of this reloading batch.

When unloading a modulefile, following actions are triggered:

* Dependent Unload: unload of the modulefiles declaring a non-op-
tional prereq or a via requirement onto unloaded modulefile or a
modulefile part of this unloading batch. A prereq modulefile is
considered optional if the prereq definition order is made of mul-
tiple modulefiles and at least one alternative modulefile is
loaded.

* Useless Requirement Unload: unload of the prereq modulefiles that
have been automatically loaded for either the unloaded modulefile,
an unloaded dependent modulefile or a modulefile part of this use-
less requirement unloading batch. Modulefiles are added to this
unloading batch only if they are not required by any other loaded
modulefiles and if they are not tagged keep-loaded, sticky or su-
per-sticky.

* Dependent Reload: reload of the modulefiles declaring a conflict
or an optional prereq onto either the unloaded modulefile, an un-
loaded dependent or an unloaded useless requirement or declaring a
prereq or a via requirement onto a modulefile part of this reload-
ing batch.

In case a loaded modulefile has some of its declared constraints un-
satisfied (pre-required modulefile not loaded or conflicting module-
file loaded for instance), this loaded modulefile is excluded from
the automatic reload actions described above.

For the specific case of the switch sub-command, where a modulefile
is unloaded to then load another modulefile. Dependent modulefiles
to Unload are merged into the Dependent modulefiles to Reload that
are reloaded after the load of the switched-to modulefile. Such
process also applies to the Dependent Unload modulefiles of Conflict
Unload modules.

The reload phase of all Dependent Reload modulefiles occurs after
the evaluation of the main modulefile (either load, unload or switch
evaluation).

The reload phase of a Dependent Reload modulefile is skipped if any
of the following conditions are met:

* The required modules for this modulefile are not loaded.

* A conflict is detected with the currently loaded environment.

* The enabled modulepaths have changed, and the modulefile is no
longer available.

However, reload is always attempted if the modulefile is tagged as
super-sticky or sticky, and force mode is not enabled. Abort on er-
ror behavior is applied if reload of such module kind fails whatever
the value of the abort_on_error configuration option. Dependent Re-
load modulefiles whose reload has been skipped are treated as Depen-
dent Unload modulefiles.

Conflict Unload mechanism is activated only if conflict_unload con-
figuration option is also enabled.

This environment variable value supersedes the default value set on
the auto_handling configuration option. It can be defined with the
config sub-command. The --auto and --no-auto command line switches
override this environment variable.

MODULES_AVAIL_INDEPTH
If set to 1, enable in depth search results for avail sub-command.
If set to 0 disable avail sub-command in depth mode. Other values
are ignored.

When in depth mode is enabled, modulefiles and directories contained
in directories matching search query are also included in search re-
sults. When disabled these modulefiles and directories contained in
matching directories are excluded.

This environment variable value supersedes the default value set in
the avail_indepth configuration option. It can be defined with the
config sub-command. The --indepth and --no-indepth command line
switches override this environment variable.

MODULES_AVAIL_OUTPUT
A colon separated list of the elements to report in addition to mod-
ule names on avail sub-command regular output mode.

Accepted elements that can be set in value list are:

* alias: module aliases.

* provided-alias: show module aliases and evaluate all modulefiles
to get aliases provided by them.

* dirwsym: directories associated with symbolic versions.

* hidden: show all hidden modules.

* indesym: symbolic versions reported independently from the module
or directory they are attached to.

* key: legend appended at the end of the output to explain it.

* modulepath: modulepath names set as header prior the list of
available modules found in them.

* sym: symbolic versions associated with available modules.

* tag: tags associated with available modules.

* variant: variants and their possible values associated with avail-
able modules.

* variantifspec: like variant but only if a variant has been speci-
fied in search query.

* via: mention next to modulepath name which loaded module enables
it if any.

The order of the elements in the list does not matter. Module names
are the only content reported when LIST is set to an empty value.

In case the modulepath element is missing from value list, the
available modules from global/user rc and all enabled modulepaths
are reported as a single list.

When indesym element is set, dirwsym and sym elements are disabled.

This environment variable value supersedes the default value set in
the avail_output configuration option. It can be defined with the
config sub-command. The --output/-o command line switches override
this environment variable.

MODULES_AVAIL_TERSE_OUTPUT
A colon separated list of the elements to report in addition to mod-
ule names on avail sub-command terse output mode.

See MODULES_AVAIL_OUTPUT to get the accepted elements that can be
set in value list. Exception for via element which is not accepted
for terse output mode.

The order of the elements in the list does not matter. Module names
are the only content reported when LIST is set to an empty value.

This environment variable value supersedes the default value set in
the avail_terse_output configuration option. It can be defined with
the config sub-command. The --output/-o command line switches over-
ride this environment variable.

MODULES_CACHE_BUFFER_BYTES
Size of the buffer used when reading or writing cache files. Ac-
cepted values are integers comprised between 4096 and 1000000.

MODULES_CACHE_EXPIRY_SECS
Number of seconds a cache file is considered valid after being gen-
erated. For example, if set to 3600 it means a cache file expires
one hour after being generated and is then ignored.

When set to 0 cache file never expires. Accepted values are integers
comprised between 0 (cache files never expire) and 31536000 (equiva-
lent to one year duration).

MODULES_CMD
The location of the active module command script.

This environment variable is generated by module command and should
not be modified externally.

MODULES_COLLECTION_PIN_VERSION
If set to 1, register exact version number of modulefiles when sav-
ing a collection. Otherwise modulefile version number is omitted if
it corresponds to the explicitly set default version and also to the
implicit default when the configuration option implicit_default is
enabled.

This environment variable value supersedes the default value set in
the collection_pin_version configuration option. It can be defined
with the config sub-command.

MODULES_COLLECTION_PIN_TAG
If set to 1, register all tags applying to modulefiles when saving a
collection. Otherwise only the extra tags set through the --tag op-
tion and tags resulting from specific module states (like
auto-loaded and keep-loaded tags) are recorded in collection. Note
that the nearly-forbidden tag due to its temporal meaning is not
saved in collection even when this configuration option is enabled.

This environment variable value supersedes the default value set in
the collection_pin_tag configuration option. It can be defined with
the config sub-command.

MODULES_COLLECTION_TARGET
The collection target that determines what collections are valid
thus reachable on the current system.

Collection directory may sometimes be shared on multiple machines
which may use different modules setup. For instance modules users
may access with the same HOME directory multiple systems using dif-
ferent OS versions. When it happens a collection made on machine 1
may be erroneous on machine 2.

When a target is set, only the collections made for that target are
available to the restore, savelist, saveshow, saverm, stash,
stashpop, stashlist, stashshow, and stashrm sub-commands. Saving a
collection registers the target footprint by suffixing the collec-
tion filename with .$MODULES_COLLECTION_TARGET. The collection tar-
get is not involved when collection is specified as file path on the
saveshow, restore and save sub-commands.

For example, the MODULES_COLLECTION_TARGET variable may be set with
results from commands like lsb_release, hostname, dnsdomainname,
etc.

This environment variable value supersedes the default value set in
the collection_target configuration option. It can be defined with
the config sub-command.

MODULES_COLOR
Defines if output should be colored or not. Accepted values are
never, auto and always.

When color mode is set to auto, output is colored only if the stan-
dard error output channel is attached to a terminal.

This environment variable value supersedes the default value set in
the color configuration option. It can be defined with the config
sub-command. The --color command line switch overrides this environ-
ment variable.

NO_COLOR, CLICOLOR and CLICOLOR_FORCE environment variables are also
honored to define color mode. The never mode is set if NO_COLOR is
defined (regardless of its value) or if CLICOLOR equals to 0. If
CLICOLOR is set to another value, it corresponds to the auto mode.
The always mode is set if CLICOLOR_FORCE is set to a value different
than 0. NO_COLOR variable prevails over CLICOLOR and CLI-
COLOR_FORCE. Color mode set with these three variables is superseded
by mode set with MODULES_COLOR environment variable or with --color
command line switch..

MODULES_COLORS
Specifies the colors and other attributes used to highlight various
parts of the output. Its value is a colon-separated list of output
items associated to a Select Graphic Rendition (SGR) code. It fol-
lows the same syntax than LS_COLORS.

Output items are designated by keys. Items able to be colorized are:
highlighted element (hi), debug information (db), trace information
(tr), tag separator (se); Error (er), warning (wa), module error
(me) and info (in) message prefixes; Modulepath (mp), directory
(di), module alias (al), module variant (va), module symbolic ver-
sion (sy), module default version (de) and modulefile command (cm).

Module tags can also be colorized. The key to set in the color
palette to get a graphical rendering of a tag is the tag name or the
tag abbreviation if one is defined for tag. The SGR code applied to
a tag name is ignored if an abbreviation is set for this tag thus
the SGR code should be defined for this abbreviation to get a graph-
ical rendering. Each basic tag has by default a key set in the color
palette, based on its abbreviated string: auto-loaded (aL), forbid-
den (F), hidden and hidden-loaded (H), loaded (L), nearly-forbidden
(nF), sticky (S), super-sticky (sS), keep-loaded (kL) and warning
(W).

See the Select Graphic Rendition (SGR) section in the documentation
of the text terminal that is used for permitted values and their
meaning as character attributes. These substring values are integers
in decimal representation and can be concatenated with semicolons.
Modules takes care of assembling the result into a complete SGR se-
quence (\33[...m). Common values to concatenate include 1 for bold,
4 for underline, 30 to 37 for foreground colors and 90 to 97 for
16-color mode foreground colors. See also -
https://en.wikipedia.org/wiki/ANSI_escape_code#Select_Graphic_Rendi-
tion_parameters for a complete SGR code reference.

No graphical rendition will be applied to an output item that could
normally be colored but which is not defined in the color set. Thus
if MODULES_COLORS is defined empty, no output will be colored at
all.

This environment variable value supersedes the default value set in
the colors configuration option. It can be defined with the config
sub-command.

MODULES_CONFLICT_UNLOAD
If set to 1, enable automated unload of conflicting modules when
loading a module. If set to 0, disable this automated conflict un-
load mechanism.

Conflict Unload is a mechanism part of the automated module handling
mode. To activate this mechanism, auto_handling configuration option
should also be enabled.

This environment variable value supersedes the default value set in
the conflict_unload configuration option. It can be defined with the
config sub-command.

MODULES_EDITOR
Text editor command name or path for use to open modulefile through
the edit sub-command.

This environment variable value supersedes the default value set in
the editor configuration option. It can be defined with the config
sub-command.

Text editor could also be defined through the VISUAL or EDITOR envi-
ronment variables. These environment variables are overridden by
MODULES_EDITOR.

MODULES_EXTENDED_DEFAULT
If set to 1, a specified module version is matched against starting
portion of existing module versions, where portion is a substring
separated from the rest of the version string by a . character. For
example specified modules mod/1 and mod/1.2 will match existing mod-
ulefile mod/1.2.3.

In case multiple modulefiles match the specified module version and
a single module has to be selected, the explicitly set default ver-
sion is returned if it is part of matching modulefiles. Otherwise
the implicit default among matching modulefiles is returned if de-
fined (see MODULES_IMPLICIT_DEFAULT section)

This environment variable value supersedes the default value set in
the extended_default configuration option. It can be defined with
the config sub-command.

MODULES_FAMILY_<NAME>
Module name minus version that provides for the name family in cur-
rently loaded environment. This environment variable is defined
through the use of the family modulefile command.

For instance if loading modulefile foo/1.0 defines being member of
the bar family, the MODULES_FAMILY_BAR will be set to the foo value.

This environment variable is generated by module command and should
not be modified externally.

MODULES_HIDE_AUTO_LOADED
If set to 1, tag automatically loaded modules hidden-loaded. These
modules will not appear on list sub-command unless --all option is
set.

This environment variable value supersedes the default value set in
the hide_auto_loaded configuration option. It can be defined with
the config sub-command.

MODULES_ICASE
When module specification are passed as argument to module sub-com-
mands or modulefile Tcl commands, defines the case sensitiveness to
apply to match them. When MODULES_ICASE is set to never, a case sen-
sitive match is applied in any cases. When set to search, a case in-
sensitive match is applied to the avail, list, whatis, paths,
savelist and spider sub-commands. When set to always, a case insen-
sitive match is also applied to the other module sub-commands and
modulefile Tcl commands for the module specification they receive as
argument.

This environment variable value supersedes the default value set in
the icase configuration option. It can be defined with the config
sub-command. The --icase/-i command line switches, which correspond
to the always mode, override this environment variable.

MODULES_IGNORE_CACHE
Ignore (if set to 1) or not (if set to 0) module cache.

This environment variable value supersedes the default value set in
the ignore_cache configuration option. It can be defined with the
config sub-command. The --ignore-cache command line switch overrides
this environment variable.

MODULES_IGNORE_USER_RC
Skip evaluation (if set to 1) or not (if set to 0) of user-specific
module rc file ($HOME/.modulerc).

This environment variable value supersedes the default value set in
the ignore_user_rc configuration option. It can be defined with the
config sub-command. The --ignore-user-rc command line switch over-
rides this environment variable.

MODULES_IMPLICIT_DEFAULT
Defines (if set to 1) or not (if set to 0) an implicit default ver-
sion for modules without a default version explicitly defined (see
Locating Modulefiles section in the modulefile man page).

Without either an explicit or implicit default version defined a
module must be fully qualified (version should be specified in addi-
tion to its name) to get:

* targeted by module load, switch, display, help, test and path
sub-commands.

* restored from a collection, unless already loaded in collec-
tion-specified order.

* automatically loaded by automated module handling mechanisms when
declared as module requirement, with prereq or module load module-
file commands.

An error is returned in the above situations if either no explicit
or implicit default version is defined.

This environment variable value supersedes the default value set in
the implicit_default configuration option. It can be defined with
the config sub-command. This environment variable is ignored if
implicit_default has been declared locked in locked_configs configu-
ration option.

MODULES_IMPLICIT_REQUIREMENT
Defines (if set to 1) or not (if set to 0) an implicit prereq or
conflict requirement onto modules specified respectively on module
load or module unload commands in modulefile. When enabled an im-
plicit conflict requirement onto switched-off module and a prereq
requirement onto switched-on module are also defined for module
switch commands used in modulefile.

This environment variable value supersedes the default value set in
the implicit_requirement configuration option. It can be defined
with the config sub-command. The --not-req option, applied to a
module command in a modulefile, overrides this environment variable.

MODULES_LIST_OUTPUT
A colon separated list of the elements to report in addition to mod-
ule names on list sub-command regular output mode.

Accepted elements that can be set in value list are:

* alias: module aliases targeting loaded modules.

* header: sentence to introduce the list of loaded modules or to
state that no modules are loaded currently.

* hidden: show hidden loaded modules.

* idx: index position of each loaded module.

* indesym: symbolic versions reported independently from the loaded
module they are attached to.

* key: legend appended at the end of the output to explain it.

* variant: variant values selected for loaded modules.

* sym: symbolic versions associated with loaded modules.

* tag: tags associated with loaded modules.

The order of the elements in the list does not matter. Module names
are the only content reported when LIST is set to an empty value.

This environment variable value supersedes the default value set in
the list_output configuration option. It can be defined with the
config sub-command. The --output/-o command line switches override
this environment variable.

MODULES_LIST_TERSE_OUTPUT
A colon separated list of the elements to report in addition to mod-
ule names on list sub-command terse output mode.

See MODULES_LIST_OUTPUT to get the accepted elements that can be set
in value list.

The order of the elements in the list does not matter. Module names
are the only content reported when LIST is set to an empty value.

This environment variable value supersedes the default value set in
the list_terse_output configuration option. It can be defined with
the config sub-command. The --output/-o command line switches over-
ride this environment variable.

MODULES_LOGGED_EVENTS
A colon separated list of the events to log. Accepted events that
can be set in value list are:

* auto_eval: log automatically triggered modulefile evaluations

* requested_eval: log modulefile evaluations directly requested by
user

* requested_cmd: log module commands directly requested by user

This environment variable value supersedes the default value set in
the logged_events configuration option. It can be defined with the
config sub-command. This environment variable is ignored if
logged_events has been declared locked in locked_configs configura-
tion option.

MODULES_LOGGER
Command to log informational messages. The value of this variable is
composed of a logger command name or path eventually followed by
command-line options.

This environment variable value supersedes the default value set in
the logger configuration option. It can be defined with the config
sub-command. This environment variable is ignored if logger has been
declared locked in locked_configs configuration option.

If MODULES_LOGGER variable is set to an empty string, logger will
not be launched.

MODULES_MCOOKIE_CHECK
If set to eval, the Modules magic cookie (i.e., #%Module file signa-
ture) is only checked to determine if a file is a modulefile when
evaluating these files. If set to always, the Modules magic cookie
is also checked when searching for modules.

The eval mode is made to significantly reduce file checks when walk-
ing through modulepaths to search for modulefiles. Special care
should be given to the content of modulepaths when this eval mode is
set as the following kind of files are included in search results:

* modulefiles with a magic cookie requiring a higher version of mod-
ulecmd.tcl

* files not beginning with the magic cookie #%Module

* read-protected files

When a module cache file is available for a given modulepath, eval
mode is not applied as cache content is generated in always mode.

This environment variable value supersedes the default value set in
the mcookie_check configuration option. It can be defined with the
config sub-command.

MODULES_MCOOKIE_VERSION_CHECK
If set to 1, the version set in the Modules magic cookie in module-
file is checked against the current version of modulecmd.tcl to de-
termine if the modulefile can be evaluated.

When a module cache file is available for a given modulepath, ver-
sion check is considered enabled as cache content is generated in
this mode.

This environment variable value supersedes the default value set in
the mcookie_version_check configuration option. It can be defined
with the config sub-command.

MODULES_ML
If set to 1, define ml command when initializing Modules (see
Package Initialization section). If set to 0, ml command is not de-
fined.

This environment variable value supersedes the default value set in
the ml configuration option. It can be defined with the config
sub-command.

To enable or disable ml command, MODULES_ML should be set prior Mod-
ules initialization or the ml configuration option should be set in
the initrc configuration file.

MODULES_NEARLY_FORBIDDEN_DAYS
Number of days a module is considered nearly forbidden prior reach-
ing its expiry date set by module-forbid modulefile command. When a
nearly forbidden module is evaluated a warning message is issued to
inform module will soon be forbidden. If set to 0, modules will
never be considered nearly forbidden. Accepted values are integers
comprised between 0 and 365.

This environment variable value supersedes the default value set in
the nearly_forbidden_days configuration option. It can be defined
with the config sub-command.

MODULES_PAGER
Text viewer for use to paginate message output if error output
stream is attached to a terminal. The value of this variable is com-
posed of a pager command name or path eventually followed by com-
mand-line options.

This environment variable value supersedes the default value set in
the pager configuration option. It can be defined with the config
sub-command.

If MODULES_PAGER variable is set to an empty string or to the value
cat, pager will not be launched.

Pager is never launched if modulecmd.tcl program is run for script-
ing language rather shells.

MODULES_PROTECTED_ENVVARS
A colon separated list of environment variable names that should not
be modified by any modulefile command.

Prevents modifications by append-path, prepend-path, remove-path,
setenv and unsetenv. When these modulefile commands attempt to mod-
ify a protected environment variable, a warning message is emitted
and modification is ignored.

This environment variable value supersedes the default value set in
the protected_envvars configuration option. It can be defined with
the config sub-command.

MODULES_QUARANTINE_SUPPORT
If set to 1, produces the shell code for quarantine mechanism when
the autoinit sub-command generates the module shell function.

The generated shell code for quarantine mechanism indirectly passes
the environment variable defined in MODULES_RUN_QUARANTINE to the
modulecmd.tcl script to protect its run-time environment from
side-effect coming from the current definition of these variables.

To enable quarantine support, MODULES_QUARANTINE_SUPPORT should be
set to 1 prior Modules initialization or the quarantine_support con-
figuration should be set to 1 in the initrc configuration file.

Generated code for quarantine mechanism sets the
__MODULES_QUARANTINE_SET environment variable when calling the mod-
ulecmd.tcl script to make it restore the environment variable put in
quarantine.

This environment variable value supersedes the default value set in
the quarantine_support configuration option. It can be defined with
the config sub-command.

MODULES_REDIRECT_OUTPUT
If set to 0, the output generated by module command is kept on
stderr and not redirected to stdout channel.

This environment variable value supersedes the default value set in
the redirect_output configuration option. It can be defined with the
config sub-command. The --redirect and --no-redirect command line
switches override this environment variable.

MODULES_REQUIRE_VIA
If set to 1, consider loaded module that enables a modulepath
(through the use of the modulefile commands module use, append-path
MODULEPATH, or prepend-path MODULEPATH) a requirement for loaded
modules stored in this modulepath. If set to 0, no dependency is
made between these modules.

This environment variable value supersedes the default value set in
the require_via configuration option. It can be defined with the
config sub-command.

MODULES_RESET_TARGET_STATE
Defines behavior of reset sub-command. When set to __init__, initial
environment is restored. When set to __purge__, reset performs a
purge sub-command. Any other value designates a name collection to
restore.

This environment variable value supersedes the default value set in
the reset_target_state configuration option. It can be defined with
the config sub-command.

MODULES_RUN_QUARANTINE
A space separated list of environment variable names that should be
passed indirectly to modulecmd.tcl to protect its run-time environ-
ment from side-effect coming from their current definition.

If the quarantine mechanism has been included in module shell func-
tion (see MODULES_QUARANTINE_SUPPORT), each variable found in
MODULES_RUN_QUARANTINE will have its value emptied or set to the
value of the corresponding MODULES_RUNENV_<VAR> variable when defin-
ing modulecmd.tcl run-time environment.

Original values of these environment variables set in quarantine are
passed to modulecmd.tcl via __MODULES_QUAR_<VAR> variables.

This environment variable value supersedes the default value set in
the run_quarantine configuration option. It can be defined with the
config sub-command.

MODULES_RUNENV_<VAR>
Value to set to environment variable <VAR> for modulecmd.tcl
run-time execution if <VAR> is referred in MODULES_RUN_QUARANTINE.

MODULES_SEARCH_MATCH
When searching for modules with avail, list, spider or collections
with savelist sub-commands, defines the way query string should
match against available module/collection names. With starts_with
value, returned modules/collections are those whose name begins by
search query string. When set to contains, any modules/collections
whose fully qualified name contains search query string are re-
turned.

This environment variable value supersedes the default value set in
the search_match configuration option. It can be defined with the
config sub-command. The --starts-with and --contains command line
switches override this environment variable.

MODULES_SET_SHELL_STARTUP
If set to 1, defines when module command initializes the shell
startup file to ensure that the module command is still defined in
sub-shells. Setting shell startup file means defining the ENV and
BASH_ENV environment variable to the Modules bourne shell initial-
ization script. If set to 0, shell startup file is not defined.

This environment variable value supersedes the default value set in
the set_shell_startup configuration option. It can be defined with
the config sub-command.

To enable shell startup file, MODULES_SET_SHELL_STARTUP should be
set to 1 prior Modules initialization or the set_shell_startup con-
figuration option should be set to 1 in the initrc configuration
file.

MODULES_SHELLS_WITH_KSH_FPATH
A list of shell on which the FPATH environment variable should be
defined at initialization time to point to the ksh-functions direc-
tory where the ksh initialization script for module command is lo-
cated. It enables for the listed shells to get module function de-
fined when starting ksh as sub-shell from there.

Accepted values are a list of shell among sh, bash, csh, tcsh and
fish separated by colon character (:).

This environment variable value supersedes the default value set in
the shells_with_ksh_fpath configuration option. It can be defined
with the config sub-command.

To enable the setup of FPATH for some shells,
MODULES_SHELLS_WITH_KSH_FPATH should be set to the list of these
shells prior Modules initialization or the shells_with_ksh_fpath
configuration option should be set to the list of these shells in
the initrc configuration file.

MODULES_SILENT_SHELL_DEBUG
If set to 1, disable any xtrace or verbose debugging property set on
current shell session for the duration of either the module command
or the module shell initialization script. Only applies to Bourne
Shell (sh) and its derivatives.

This environment variable value supersedes the default value set in
the silent_shell_debug configuration option. It can be defined with
the config sub-command.

To generate the code to silence shell debugging property in the mod-
ule shell function, MODULES_SILENT_SHELL_DEBUG should be set to 1
prior Modules initialization or the silent_shell_debug configuration
option should be set to 1 in the initrc configuration file.

MODULES_SITECONFIG
Location of a site-specific configuration script to source into mod-
ulecmd.tcl. See Site-specific configuration section for details.

This environment variable value supersedes the default value set in
the extra_siteconfig configuration option. It can be defined with
the config sub-command. This environment variable is ignored if
extra_siteconfig has been declared locked in locked_configs configu-
ration option.

MODULES_SOURCE_CACHE
If set to 1, cache content of files evaluated in modulefile through
source(n) Tcl command. When same file is sourced multiple times,
cached content is reused rather reading file again.

This environment variable value supersedes the default value set in
the source_cache configuration option. It can be defined with the
config sub-command.

MODULES_SPIDER_INDEPTH
If set to 1, enable in depth search results for spider sub-command.
If set to 0 disable spider sub-command in depth mode. Other values
are ignored.

This environment variable value supersedes the default value set in
the spider_indepth configuration option. It can be defined with the
config sub-command. The --indepth and --no-indepth command line
switches override this environment variable.

MODULES_SPIDER_OUTPUT
A colon separated list of the elements to report in addition to mod-
ule names on spider sub-command regular output mode.

Accepted elements that can be set in value list are:

* alias: module aliases.

* provided-alias: show module aliases and evaluate all modulefiles
to get aliases provided by them.

* dirwsym: directories associated with symbolic versions.

* hidden: show all hidden modules.

* indesym: symbolic versions reported independently from the module
or directory they are attached to.

* key: legend appended at the end of the output to explain it.

* modulepath: modulepath names set as header prior the list of
available modules found in them.

* sym: symbolic versions associated with available modules.

* tag: tags associated with available modules.

* variant: variants and their possible values associated with avail-
able modules.

* variantifspec: like variant but only if a variant has been speci-
fied in search query.

* via: mention next to modulepath name which module enables it if
any.

The order of the elements in the list does not matter. Module names
are the only content reported when LIST is set to an empty value.

In case the modulepath element is missing from value list, the
available modules from global/user rc and all enabled modulepaths
are reported as a single list.

When indesym element is set, dirwsym and sym elements are disabled.

This environment variable value supersedes the default value set in
the spider_output configuration option. It can be defined with the
config sub-command. The --output/-o command line switches override
this environment variable.

MODULES_SPIDER_TERSE_OUTPUT
A colon separated list of the elements to report in addition to mod-
ule names on spider sub-command terse output mode.

See MODULES_SPIDER_OUTPUT to get the accepted elements that can be
set in value list. Exception for via element which is not accepted
for terse output mode.

The order of the elements in the list does not matter. Module names
are the only content reported when LIST is set to an empty value.

This environment variable value supersedes the default value set in
the spider_terse_output configuration option. It can be defined with
the config sub-command. The --output/-o command line switches over-
ride this environment variable.

MODULES_STICKY_PURGE
When unloading a sticky or super-sticky module during a module
purge, raise an error or emit a warning message or be silent.

This environment variable value supersedes the default value set in
the sticky_purge configuration option. It can be defined with the
config sub-command.

MODULES_TAG_ABBREV
Specifies the abbreviation strings used to report module tags (see
Module tags section). Its value is a colon-separated list of module
tag names associated to an abbreviation string (e.g. tagname=ab-
brev).

If a tag is associated to an empty string abbreviation, this tag
will not be reported. In case the whole MODULES_TAG_ABBREV environ-
ment variable is set to an empty string, tags are reported but not
abbreviated.

This environment variable value supersedes the default value set in
the tag_abbrev configuration option. It can be defined with the
config sub-command.

MODULES_TAG_COLOR_NAME
Specifies the tag names or abbreviations whose graphical rendering
should be applied over themselves instead of being applied over the
name of the module they are attached to. Value of
MODULES_TAG_COLOR_NAME is a colon-separated list of module tag names
or abbreviation strings (see Module tags section).

When a select graphic rendition is defined for a tag name or a tag
abbreviation string, it is applied over the module name associated
with the tag and tag name or abbreviation is not displayed. When
listed in MODULES_TAG_COLOR_NAME environment variable, a tag name or
abbreviation is displayed and select graphic rendition is applied
over it.

This environment variable value supersedes the default value set in
the tag_color_name configuration option. It can be defined with the
config sub-command.

MODULES_TCL_LINTER
Command name or path for use to check syntax of modulefile through
the lint sub-command.

This environment variable value supersedes the default value set in
the tcl_linter configuration option. It can be defined with the
config sub-command.

MODULES_TERM_BACKGROUND
Inform Modules of the terminal background color to determine if the
color set for dark background or the color set for light background
should be used to color output in case no specific color set is de-
fined with the MODULES_COLORS variable. Accepted values are dark and
light.

This environment variable value supersedes the default value set in
the term_background configuration option. It can be defined with the
config sub-command.

MODULES_TERM_WIDTH
Specifies the number of columns of the output. If set to 0, the out-
put width will be the full terminal width, which is automatically
detected by the module command. Accepted values are integers com-
prised between 0 and 1000.

This environment variable value supersedes the default value set in
the term_width configuration option. It can be defined with the
config sub-command. The --width/-w command line switches override
this environment variable.

MODULES_UNIQUE_NAME_LOADED
If set to 1, allows only one module loaded per module name. A con-
flict is raised when loading a module whose name or alternative
names are shared by an already loaded module.

This environment variable value supersedes the default value set in
the unique_name_loaded configuration option. It can be defined with
the config sub-command.

MODULES_UNLOAD_MATCH_ORDER
When a module unload request matches multiple loaded modules, unload
firstly loaded module or lastly loaded module. Accepted values are
returnfirst and returnlast.

This environment variable value supersedes the default value set in
the unload_match_order configuration option. It can be defined with
the config sub-command.

MODULES_VARIANT_SHORTCUT
Specifies the shortcut characters that could be used to specify and
report module variants (see Module variants section). Its value is a
colon-separated list of variant names associated to a shortcut char-
acter (e.g., variantname=shortcutchar).

A variant shortcut must be of one character length and must avoid
characters used for other concerns or in module names or version
specifications (i.e., [-+~/@=:,a-zA-Z0-9]).

If a shortcut is associated to an empty string or an invalid charac-
ter, this shortcut definition will be ignored.

This environment variable value supersedes the default value set in
the variant_shortcut configuration option. It can be defined with
the config sub-command.

MODULES_VERBOSITY
Defines the verbosity level of the module command. Available ver-
bosity levels from the least to the most verbose are:

* silent: turn off error, warning and informational messages but
does not affect module command output result.

* concise: enable error and warning messages but disable informa-
tional messages.

* normal: turn on informational messages, like a report of the addi-
tional module evaluations triggered by loading or unloading mod-
ules, aborted evaluation issues or a report of each module evalua-
tion occurring during a restore or source sub-commands.

* verbose: add additional informational messages, like a systematic
report of the loading or unloading module evaluations.

* verbose2: report loading or unloading module evaluations of hid-
den-loaded modules, report if loading module is already loaded or
if unloading module is not loaded.

* trace: provide details on module searches, resolutions, selections
and evaluations.

* debug: print debugging messages about module command execution.

* debug2: report modulecmd.tcl procedure calls in addition to print-
ing debug messages.

This environment variable value supersedes the default value set in
the verbosity configuration option. It can be defined with the
config sub-command. The --silent, --verbose, --debug and --trace
command line switches override this environment variable.

MODULES_WA_277
If set to 1 prior to Modules package initialization, enables
workaround for Tcsh history issue (see -
https://github.com/envmodules/modules/issues/277). This issue leads
to erroneous history entries under Tcsh shell. When workaround is
enabled, an alternative module alias is defined which fixes the his-
tory mechanism issue. However the alternative definition of the mod-
ule alias weakens shell evaluation of the code produced by module-
files. Characters with a special meaning for Tcsh shell (like { and
}) may not be used anymore in shell alias definition otherwise the
evaluation of the code produced by modulefiles will return a syntax
error.

This environment variable value supersedes the default value set in
the wa_277 configuration option. It can be defined with the config
sub-command.

To enable this workaround, MODULES_WA_277 should be set to 1 prior
Modules initialization or the wa_277 configuration option should be
set to 1 in the initrc configuration file.

MODULESHOME
The location of the main Modules package file directory containing
module command initialization scripts, the executable program mod-
ulecmd.tcl, and a directory containing a collection of main module-
files.

This environment variable value supersedes the default value set in
the home configuration option. It can be defined with the config
sub-command.

FILES
/usr/local/Modules/5.6.1
The MODULESHOME directory.

/usr/local/Modules/5.6.1/etc/initrc
The configuration file evaluated by modulecmd.tcl when it initializes to
enable the default modulepaths, load the default modules and set module
command configuration.

initrc is a modulefile so it is written as a Tcl script and defines mod-
ulepaths to enable with module use, modules to load with module load and
configuration to apply with module config. As any modulefile initrc must
begin with the Modules magic cookie (i.e., #%Module file signature).

initrc is optional. When this configuration file is present it is evalu-
ated after the modulespath configuration file. See the Package Initial-
ization section for details.

/usr/local/Modules/5.6.1/etc/modulespath
The configuration file evaluated by modulecmd.tcl when it initializes to
enable the default modulepaths. This file contains the list of mod-
ulepaths separated by either newline or colon characters.

modulespath is optional. When this configuration file is present it is
evaluated before the initrc configuration file. See the Package Initial-
ization section for details.

/usr/local/Modules/5.6.1/etc/siteconfig.tcl
The site-specific configuration script of modulecmd.tcl. An additional
configuration script could be defined using the MODULES_SITECONFIG envi-
ronment variable. See Site-specific configuration for detailed informa-
tion.

/usr/local/Modules/5.6.1/etc/rc
The system-wide modules rc file. The location of this file can be
changed using the MODULERCFILE environment variable as described above.

$HOME/.modulerc
The user specific modules rc file.

$HOME/.module
The user specific collection directory.

/usr/local/Modules/5.6.1/modulefiles
The directory for system-wide modulefiles. The location of the directory
can be changed using the MODULEPATH environment variable as described
above.

<modulepath>/.modulerc
Modulepath-specific module rc file.

<modulepath>/.modulecache
Modulepath-specific module cache file.

/usr/local/Modules/5.6.1/libexec/modulecmd.tcl
The modulefile interpreter that gets executed upon each invocation of
module.

/usr/local/Modules/5.6.1/init/<shell>
The Modules package initialization file sourced into the user's environ-
ment.

Header And Logo

Peripheral Links

Site Navigation

FreeBSD Manual Pages

Header And Logo

Peripheral Links

Search

Site Navigation

FreeBSD Manual Pages