module — Modules documentation (original) (raw)

SYNOPSIS

module [_switches_] [sub-command [_sub-command-args_]]

DESCRIPTION

module is a user interface to the Modules package. The Modules package provides for the dynamic modification of the user's environment via modulefiles.

Each modulefile contains the information needed to configure the shell for an application. Once the Modules package is initialized, the environment can be modified on a per-module basis using the modulecommand which interprets modulefiles. Typically modulefiles instruct the module command to alter or set shell environment variables such as PATH, MANPATH, etc. Modulefiles may be shared by many users on a system and users may have their own 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 summarized through the module command as well. If no arguments are given, a summary of the module usage and sub-commands are shown.

The action for the module command to take is described by the_sub-command_ and its associated arguments.

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.tclprogram located in /usr/share/Modules/libexec for the corresponding shell. The output of this execution is evaluated by shell which creates the modulecommand as either an alias or function and creates Modules environment variables.

During this initialization process, if the Modules environment is found undefined (when both MODULEPATH and LOADEDMODULES are found either unset or empty), the modulespath and initrcconfiguration files located in /etc/environment-modules are evaluated if present and following this order. modulespath file contains the list of modulepaths to enable during initialization. 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 defined 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.tclprogram and has the shell evaluate the command's output. The first argument tomodulecmd.tcl specifies the type of shell.

The initialization scripts are kept in /usr/share/Modules/init/<shell> where__ is the name of the sourcing shell. For example, a C Shell user sources the /usr/share/Modules/init/csh script. The sh, csh, tcsh, bash, ksh, zsh, fish and cmd shells are supported 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 theautoinit sub-command of the modulecmd.tcl program.

A ml alias or function may also be defined at initialization time if enabled (see MODULES_ML section). ml is a handy frontend leveraging all module command capabilities with less character typed. See ml for detailed information.

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 executedmogui.

Changed in version 5.5: Definition of mogui alias or function added

Examples of initialization

C Shell initialization (and derivatives):

source /usr/share/Modules/init/csh module load modulefile modulefile ...

Bourne Shell (sh) (and derivatives):

. /usr/share/Modules/init/sh module load modulefile modulefile ...

PowerShell (pwsh):

. /usr/share/Modules/init/pwsh.ps1 envmodule load modulefile modulefile ...

Perl:

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

Python:

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

Ruby:

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

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

eval "$(/usr/share/Modules/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/etc/environment-modules/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:

Global RC file(s) as specified by MODULERCFILE variable or/etc/environment-modules/rc. If a path element in MODULERCFILE points to a directory, the modulerc file in this directory is used as a global RC file.
User specific module RC file $HOME/.modulerc
All .modulerc and .version files found during modulefile seeking.

These module run-command files must begins like modulefiles with the#%Module 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-command file is compatible. Files without the magic cookie or with a version number greater than the current version ofmodulecmd.tcl will not be interpreted and an error is reported. Such error does not abort the whole module evaluation. If themcookie_version_check configuration is disabled the version 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 or whatis sub-commands. Hard-hidden modules are not affected by this option.

Added in version 4.6.

Changed in version 4.7: Support for list sub-command added

Changed in version 5.2: Support for lint and savelist sub-commands added

--auto

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

Added in version 4.2.

--color=

Colorize the output. WHEN defaults to always or can be never orauto. See also MODULES_COLOR section.

Added in version 4.3.

--contains, -C

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

Added in version 4.3.

Changed in version 5.1: Support for list sub-command added

Changed in version 5.2: Support for savelist sub-command added

--debug, -D, -DD

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

Added in version 4.0.

Changed in version 4.6: Option form -DD added

--default, -d

On avail sub-command, 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 optionimplicit_default is enabled (see Locating Modulefilessection in the modulefile man page for further details on implicit default version).

Added in version 4.0.

--force, -f

On load, unload, switch, load-any,try-load, mod-to-sh and source sub-commands by-pass any unsatisfied modulefile constraint corresponding to the declaredprereq 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 required as a prereq by another modulefile.

On load, ml, mod-to-sh, purge,reload, switch, try-load and unloadsub-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 andunload 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.

Added in version 4.3: --force/-f support was dropped on version 4.0but reintroduced starting version 4.2 with a different meaning: instead of enabling an active dependency resolution mechanism--force command line switch now enables to by-pass dependency consistency when loading or unloading a modulefile.

Changed in version 4.7: Support for purge sub-command added

Changed in version 4.8: Support for try-load sub-command added

Changed in version 5.1: Support for load-any sub-command added

Changed in version 5.2: Support for mod-to-sh sub-command added

Changed in version 5.4: Unloads modulefile anyway even if an evaluation error occurs

Changed in version 5.4: Disables abort_on_error configuration option

--help, -h

Give some helpful usage information, and terminates the command.

--icase, -i

Match module specification arguments in a case insensitive manner.

Added in version 4.4: --icase/-i support was dropped on version 4.0but reintroduced starting version 4.4. When set, it now applies to search query string and module specification on all sub-commands and modulefile Tcl commands.

--ignore-cache

Ignore module cache.

Added in version 5.3.

--ignore-user-rc

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

Added in version 5.3.

--indepth

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

Added in version 4.3.

--json, -j

Display avail, list, savelist,stashlist, whatis and search output in JSON format.

Added in version 4.5.

--latest, -L

On avail sub-command, display only the highest numerically sorted version of each module name (see Locating Modulefiles section in themodulefile man page).

Added in version 4.0.

--long, -l

Display avail, list, savelist andstashlist 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.

Added in version 4.2.

--no-indepth

On avail sub-command, limit search results to the matching modulefiles and directories found at the depth level expressed by the search query. Thus modulefiles contained in directories part of the result are excluded.

Added in version 4.3.

Do not pipe message output into a pager.

Added in version 4.1.

--no-redirect

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

Added in version 5.1.

--output=LIST, -o LIST

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

Accepted elements in LIST for avail sub-command are:modulepath, alias, dirwsym, indesym, sym, tag, key, _variant_and variantifspec.

Accepted elements in LIST for list sub-command are: header,idx, variant, alias, indesym, sym, tag 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.

Added in version 4.7.

Changed in version 4.8: Element variant added for list sub-command

Changed in version 5.3: Elements variant and variantifspec added for availsub-command

Changed in version 5.3: Prefixes + and - added to append and subtract elements

Changed in version 5.3.1: Element indesym added for avail sub-command

Changed in version 5.4: Elements alias and indesym added for list sub-command

--paginate

Pipe all message output into less (or if set, to the command referred in MODULES_PAGER variable) if error output stream is a terminal. See also MODULES_PAGER section.

Added in version 4.1.

--redirect

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

Added in version 5.1.

--silent, -s

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

Added in version 4.3: --silent/-s support was dropped on version 4.0but reintroduced starting version 4.3.

--starts-with, -S

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

Added in version 4.3.

Changed in version 5.1: Support for list sub-command added

Changed in version 5.2: Support for savelist sub-command added

--tag=LIST

On load, load-any, switch andtry-load sub-commands, apply LIST of module tags to the loading_modulefile_. LIST corresponds to the concatenation 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.

Added in version 5.1.

--terse, -t

Display avail, list, savelist andstashlist 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.

Added in version 5.2.

--trace, -T

Trace mode. Report details on module searches, resolutions, selections and evaluations in addition to printing verbose messages.

Added in version 4.6.

--verbose, -v, -vv

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

Added in version 4.3: --verbose/-v support was dropped on version 4.0but reintroduced starting version 4.3.

Changed in version 4.7: Option form -vv added

--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 alsoMODULES_TERM_WIDTH section.

Added in version 4.7.

Module Sub-Commands

add [options] modulefile...

See load.

add-any [options] modulefile...

See load-any.

Added in version 5.1.

aliases [-a]

List all available symbolic version-names and aliases in the currentMODULEPATH. All directories in the MODULEPATH are recursively searched in the same manner than for the availsub-command. Only the symbolic version-names and aliases found in the search are displayed.

Added in version 4.0.

Changed in version 4.6: Option --all/-a added

append-path [options] variable value...

Append value to environment variable. The variable is a colon, or_delimiter_, separated list. See append-path in themodulefile 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 --duplicates option is set.

Added in version 4.1.

Changed in version 5.0: Reference counter environment variable is not updated anymore unless if the --duplicates option is set

apropos [-a] [-j] string

See search.

List all available modulefiles in the current MODULEPATH. All directories in the MODULEPATH are recursively searched for files containing 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 insensitive manner by default. pattern may contain wildcard characters. Multiple versions of an application can be supported by creating 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 displayed next to the modulefile they are assigned to within parenthesis. 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 modulercsection.

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 relative 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 andMODULES_COLORS sections for details on colored output.

Module tags applying to the available modulefiles returned by theavail sub-command are reported along the module name they are associated 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). TheExtra match search process is triggered to collect variant information.

A Key section is added at the end of the output in case some elements 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, theExtra match search process is triggered to collect command information used in modulefiles. Modules are included in results only if they match_pattern_ variant specification and extra specifier. pattern may be a bare variant specification or extra specifier without mention of a module name.

Changed in version 4.0: Options --default/-d,--latest/-L added

Changed in version 4.3: Options --starts-with/-S,--contains/-C, --indepth,--no-indepth added

Changed in version 4.5: Option --json/-j added

Changed in version 4.6: Option --all/-a added

Changed in version 4.7: Key section added at end of output

Changed in version 4.7: Option --output/-o added, compatible with regular and terse output modes

Changed in version 5.3: Module variants may be reported if defined in avail output configuration

Changed in version 5.3: pattern may include variant specification or extra specifier to filter results

cachebuild [modulepath...]

Build module cache file for designated modulepaths. If no argument is provided cache file is built for every modulepath currently enabled. 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 available within modulepath.

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

Added in version 5.3.

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.

Added in version 5.3.

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 yesor y in order to proceed.

Added in version 4.3: clear support was dropped on version 4.0 but reintroduced starting version 4.3.

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 command-line switch (cmd-line) or from an environment variable (env-var). When a reported option value is locked and cannot be altered 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 prefixed 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, currentmodulecmd.tcl state and Modules-related environment variables are reported 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. TheMODULES_ABORT_ON_ERROR environment variable is defined byconfig sub-command when changing this configuration option from its default value. See MODULES_ABORT_ON_ERROR description for details.

Added in version 5.4.

advanced_version_spec

Advanced module version specification to finely select modulefiles.

Default value is 1. It can be changed at installation time with--disable-advanced-version-specoption. 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_SPECdescription for details.

Added in version 4.4.

auto_handling

Automated module handling mode.

Default value is 1. It can be changed at installation time with--disable-auto-handling option. TheMODULES_AUTO_HANDLING environment variable is defined byconfig sub-command when changing this configuration option from its default value. The --auto and --no-autocommand line switches change the value of this configuration option. SeeMODULES_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. TheMODULES_AVAIL_INDEPTH environment variable is defined byconfig sub-command when changing this configuration option from its default value. The --indepth and --no-indepthcommand line switches change the value of this configuration option. SeeMODULES_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:key. It can be changed at installation time with --with-avail-output option. TheMODULES_AVAIL_OUTPUT environment variable is defined byconfig sub-command when changing this configuration option from its default value. The --output/-o command line switches change the value of this configuration option. SeeMODULES_AVAIL_OUTPUT description for details.

Added in version 4.7.

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. It can be changed at installation time with --with-avail-terse-output option. TheMODULES_AVAIL_TERSE_OUTPUT environment variable is defined byconfig sub-command when changing this configuration option from its default value. The --output/-o command line switches change the value of this configuration option. SeeMODULES_AVAIL_TERSE_OUTPUT description for details.

Added in version 4.7.

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 variable is defined byconfig sub-command when changing this configuration option from its default value.

Added in version 5.3.

cache_expiry_secs

Number of seconds a cache file is considered valid after being generated.

Default value is 0. Values between 0 and 31536000 are accepted. The MODULES_CACHE_EXPIRY_SECS environment variable is defined byconfig sub-command when changing this configuration option from its default value.

Added in version 5.3.

collection_pin_version

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

collection_pin_tag

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

Added in version 5.1.

collection_target

Collection target which is valid for current system.

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

color

Colored output mode.

Default value is auto. It can be changed at installation time with--disable-color option. TheMODULES_COLOR environment variable is defined byconfig sub-command when changing this configuration option from its default value. The --color command 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=43:S=46:sS=44:kL=30;48;5;109. 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_COLORSenvironment variable is defined by config sub-command when changing this configuration option from its default value. SeeMODULES_COLORS description for details.

conflict_unload

Automated unload of conflicting modules when loading a module. This mechanism is part of the automated module handling mode and also requires enablement ofauto_handling configuration option.

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

Added in version 5.5.

contact

Modulefile contact address.

Default value is root@localhost. The MODULECONTACT environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULECONTACTdescription 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. TheMODULES_EXTENDED_DEFAULT environment variable is defined byconfig sub-command when changing this configuration option from its default value. See MODULES_EXTENDED_DEFAULT description for details.

Added in version 4.4.

editor

Text editor command to open modulefile with through editsub-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_EDITORdescription for details.

Added in version 4.8.

Additional site-specific configuration script location. SeeSite-specific configuration section for details.

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

hide_auto_loaded

Tag automatically loaded modules hidden-loaded

Default is 0. The MODULES_HIDE_AUTO_LOADED environment variable is defined by config sub-command when changing this configuration option from its default value.

Added in version 5.5.

home

Location of Modules package main directory.

Default value is /usr/share/Modules. It can be changed at installation time with--prefix or --with-moduleshome options. TheMODULESHOME environment variable is defined by configsub-command when changing this configuration option from its default value. See MODULESHOME description for details.

Added in version 4.4.

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.

Added in version 4.4.

ignore_cache

Ignore module cache.

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

Added in version 5.3.

ignore_user_rc

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

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

Added in version 5.3.

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. TheMODULES_IMPLICIT_DEFAULT environment variable is defined byconfig sub-command when changing this configuration option from its default value. See MODULES_IMPLICIT_DEFAULT description for details.

implicit_requirement

Implicitly define a requirement onto modules specified on modulecommands in modulefile.

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

Added in version 4.7.

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. TheMODULES_LIST_OUTPUT environment variable is defined byconfig sub-command when changing this configuration option from its default value. The --output/-o command line switches change the value of this configuration option. SeeMODULES_LIST_OUTPUT description for details.

Added in version 4.7.

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. TheMODULES_LIST_TERSE_OUTPUT environment variable is defined byconfig sub-command when changing this configuration option from its default value. The --output/-o command line switches change the value of this configuration option. SeeMODULES_LIST_TERSE_OUTPUT description for details.

Added in version 4.7.

locked_configs

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

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

logged_events

List of the events to log.

This configuration option is set to an empty value by default. It can be changed at installation time with --with-logged-events option. The MODULES_LOGGED_EVENTS environment variable is defined byconfig sub-command when changing this configuration option from its default value. See MODULES_LOGGED_EVENTS description for details.

Added in version 5.5.

logger

Command to log messages.

Default value is logger -t modules. It can be changed at installation time with --with-logger and --with-logger-optsoptions. The MODULES_LOGGER environment variable is defined byconfig sub-command when changing this configuration option from its default value. See MODULES_LOGGER description for details.

Added in version 5.5.

mcookie_check

Defines if the Modules magic cookie (i.e., #%Module file signature) should be checked to determine if a file is a modulefile.

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

Added in version 5.1.

mcookie_version_check

Defines if the version set in the Modules magic cookie used in modulefile should be checked against the version of modulecmd.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-checkoption. 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_CHECKdescription for details.

Added in version 4.7.

ml

Define ml command at initialization time.

Default value is 1. It can be changed at installation time with--disable-ml option. The MODULES_MLenvironment variable is defined by config sub-command when changing this configuration option from its default value. SeeMODULES_ML description for details.

Added in version 4.5.

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. TheMODULES_NEARLY_FORBIDDEN_DAYS environment variable is defined byconfig sub-command when changing this configuration option from its default value. See MODULES_NEARLY_FORBIDDEN_DAYS description for details.

Added in version 4.6.

Text viewer to paginate message output.

Default value is less -eFKRX. It can be changed at installation time with --with-pager and --with-pager-opts options. TheMODULES_PAGER environment variable is defined by configsub-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. TheMODULES_PROTECTED_ENVVARS environment variable is defined byconfig sub-command when changing this configuration option from its default value. See MODULES_PROTECTED_ENVVARS description for details.

Added in version 5.2.

quarantine_support

Defines if code for quarantine mechanism support should be generated inmodule shell function definition.

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

Added in version 5.0.

rcfile

Location of global run-command file(s).

This configuration option is unset by default. The MODULERCFILEenvironment variable is defined by config sub-command when changing this configuration option from its default value. SeeMODULERCFILE 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 description for details.

Added in version 5.1.

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_STATEenvironment variable is defined by config sub-command when changing this configuration option from its default value. SeeMODULES_RESET_TARGET_STATE description for details.

Added in version 5.2.

run_quarantine

Environment variables to indirectly pass to modulecmd.tcl.

This configuration option is set to an empty value by default. It can be changed at installation time with --with-quarantine-vars option that sets MODULES_RUN_QUARANTINE. This environment variable is also defined 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 installation time with --with-search-match option. TheMODULES_SEARCH_MATCH environment variable is defined byconfig sub-command when changing this configuration option from its default value. The --contains and --starts-withcommand line switches change the value of this configuration option. SeeMODULES_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. TheMODULES_SET_SHELL_STARTUP environment variable is defined byconfig sub-command when changing this configuration option from its default value. See MODULES_SET_SHELL_STARTUP description 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 default. TheMODULES_SHELLS_WITH_KSH_FPATH environment variable is defined byconfig sub-command when changing this configuration option from its default value. See MODULES_SHELLS_WITH_KSH_FPATH description for details.

Added in version 4.7.

silent_shell_debug

Disablement of shell debugging property for the module command. Also defines if code to silence shell debugging property should be generated inmodule shell function definition.

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

siteconfig

Primary site-specific configuration script location. SeeSite-specific configuration section for details.

Default value is /etc/environment-modules/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_CACHEenvironment variable is defined by config sub-command when changing this configuration option from its default value. SeeMODULES_SOURCE_CACHE description for details.

Added in version 5.4.

sticky_purge

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

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 defined byconfig sub-command when changing this configuration option from its default value. See MODULES_STICKY_PURGE description for details.

Added in version 5.4.

tag_abbrev

Abbreviations to use to report module tags.

Default value is auto-loaded=aL:loaded=L:hidden=H:hidden-loaded=H:forbidden=F:nearly-forbidden=nF:sticky=S:super-sticky=sS:keep-loaded=kL. It can be changed at installation time with --with-tag-abbrevoption. The MODULES_TAG_ABBREV environment variable is defined byconfig sub-command when changing this configuration option from its default value. See MODULES_TAG_ABBREV description for details.

Added in version 4.7.

tag_color_name

Tags whose name should be colored instead of module name.

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

Added in version 4.7.

tcl_ext_lib

Modules Tcl extension library location.

Default value is /usr/share/Modules/lib64/libtclenvmodules.so. It can be changed at installation time with --prefix or --libdir options. The value of this option cannot be altered.

tcl_linter

Command to check syntax of modulefiles with through lintsub-command.

Default value is nagelfar.tcl. It can be changed at installation time with --with-tcl-linter and --with-tcl-linter-optsoptions. The MODULES_TCL_LINTER environment variable is defined byconfig sub-command when changing this configuration option from its default value. See MODULES_TCL_LINTER description for details.

Added in version 5.2.

term_background

Terminal background color kind.

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

term_width

Set the width of the output.

Default value is 0. The MODULES_TERM_WIDTH environment variable is defined by config sub-command when changing this configuration option from its default value. The--width/-w command line switches change the value of this configuration option. See MODULES_TERM_WIDTH description for details.

Added in version 4.7.

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. TheMODULES_UNIQUE_NAME_LOADED environment variable is defined byconfig sub-command when changing this configuration option from its default value. See MODULES_UNIQUE_NAME_LOADED description for details.

Added in version 5.4.

unload_match_order

Unload firstly loaded or lastly loaded module matching request.

Default value is returnlast. It can be changed at installation time with--with-unload-match-order option. TheMODULES_UNLOAD_MATCH_ORDER environment variable is defined byconfig sub-command when changing this configuration option from its default value. See MODULES_UNLOAD_MATCH_ORDER description 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 default. It can be changed at installation time with --with-variant-shortcut option. The MODULES_VARIANT_SHORTCUT environment variable is defined byconfig sub-command when changing this configuration option from its default value. See MODULES_VARIANT_SHORTCUT description for details.

Added in version 4.8.

verbosity

Module command verbosity level.

Default value is normal. It can be changed at installation time with--with-verbosity option. The MODULES_VERBOSITYenvironment 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/-vcommand line switches change the value of this configuration option. SeeMODULES_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_277description for details.

Added in version 4.3.

Changed in version 5.3: Value prefixes + and - added to append and subtract elements to list-value options

display modulefile...

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

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 section below).

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

edit modulefile

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

Added in version 4.8.

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 error, help sequence continues.

info-loaded modulefile

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

Added in version 4.1.

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_variablesand .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 _modulefiles_are appended to any existing list of modulefiles. The module loadline must be located in at least one of the files listed above for any of the init sub-commands to work properly. If themodule 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 beginning 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 enabledMODULEPATH. Returns a false value otherwise. See is-availin the modulefile man page for further explanation.

Added in version 4.1.

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 provided. Returns a false value otherwise. See is-loaded in the modulefile man page for further explanation.

Added in version 4.1.

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.

Added in version 4.1.

is-used [directory...]

Returns a true value if any of the listed directories has been enabled inMODULEPATH or if any directory is enabled in case no argument is provided. Returns a false value otherwise. See is-used in themodulefile man page for further explanation.

Added in version 4.1.

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 and user rc files. Hidden modulefiles are also analyzed when --all/-aoption is set.

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

Added in version 5.2.

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 insensitive 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 included in results only if they match it. pattern may be a bare variant specification without mention of a module name.

Changed in version 4.5: Option --json/-j added

Changed in version 4.7: Option --all/-a added

Changed in version 4.7: Key section added at end of output

Changed in version 4.7: Option --output/-o added, compatible with regular and terse output modes.

Changed in version 4.8: Report if enabled the variants selected on loaded modules

Changed in version 5.1: pattern search to filter loaded modules added

Changed in version 5.1: Options --starts-with/-S and--contains/-C added

Changed in version 5.3: pattern may include variant specification to filter results

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 module. If module has been automatically loaded by another module, the auto-loadedtag 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 already loaded modulefiles are withdrawn if load sub-command is defined inabort_on_error configuration option and --force option is not set.

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

Changed in version 4.2: Options --auto, --no-auto,--force/-f added

Changed in version 5.1: Option --tag added

Changed in version 5.4: Support for abort_on_error configuration option added

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_modulefile_ once loaded. If module is already loaded, tags from _taglist_are added to the list of tags already applied to this module.

Added in version 5.1.

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 environment. Like forload 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 bymodulecmd.tcl. Thus it is not rendered in current environment by themodule shell function.

mod-to-sh automatically set verbosity to the silentmode, 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 error, 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-shsub-command is defined in abort_on_error configuration option and--force option is not set.

Added in version 5.2.

Changed in version 5.4: Support for abort_on_error configuration option added

path modulefile

Print path to modulefile.

Added in version 4.0.

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 section below).

Added in version 4.0.

Changed in version 5.3: pattern may include variant specification or extra specifier to filter results

prepend-path [options] variable value...

Prepend value to environment variable. The variable is a colon, or_delimiter_, separated list. See prepend-path in themodulefile 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 --duplicates option is set.

Added in version 4.1.

Changed in version 5.0: Reference counter environment variable is not updated anymore unless if the --duplicates option is set

purge [-f]

Unload all loaded modulefiles.

When the --force option is set, also unload sticky modules, modulefiles 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 unloaded and sequence is resumed with the unload of remaining modulefiles. Conversely, purge sequence is aborted and already unloaded modulefiles are restored ifpurge sub-command is defined in abort_on_errorconfiguration option and --force option is not set.

Changed in version 4.7: Option --force/-f added

Changed in version 5.4: Support for abort_on_error configuration option added

refresh

Force a refresh of all non-persistent components of currently loaded modules. This should be used on derived shells where shell completions, 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 arefresh 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 continues: environment changes from refreshed modules prior the evaluation error are preserved and sequence is resumed with the refresh of remaining modulefiles.

Changed in version 4.0: Sub-command made as an alias of reload sub-command

Changed in version 5.0: Behavior of version 3.2 refresh sub-command restored

Changed in version 5.2: Only evaluate modules listed in __MODULES_LMREFRESH

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 theprereq 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, ifreload is removed from abort_on_error configuration 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.

Added in version 4.0.

Changed in version 5.4: Support for abort_on_error configuration option added

Changed in version 5.4: Option --force/-f added

remove-path [options] variable value...

Remove value from the colon, or delimiter, separated list in environment_variable_. See remove-path in the modulefile man page for_options_ 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 whatever the reference counter value set.

Added in version 4.1.

Changed in version 5.0: value is removed whatever its reference counter value

reset [-f]

Restore initial environment, which corresponds to the loaded state afterModules 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 configuration option is set by default to __init__, which corresponds to the above behavior description. When set to __purge__,reset performs a purge of the environment. When set to any other value, reset performs a restore of corresponding name collection.

Added in version 5.2.

Changed in version 5.4: Option --force/-f added

restore [-f] [collection]

Restore the environment state as defined in collection. If _collection_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 location rather than from a file under the user's collection directory. IfMODULES_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 MODULEPATHdirectory list and the currently loaded modulefiles are unused and unloaded then used and loaded to exactly match the MODULEPATH and loaded modulefiles 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_defaultis 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 resumed with the unload or load of remaining modulefiles.

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

Added in version 4.0.

Changed in version 5.2: Restore initial environment when collection name is __init__ or when no collection name is specified and no default collection exists

Changed in version 5.4: Option --force/-f added

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 defined default module version, the bare module name is recorded. If the configuration option implicit_default is enabled, the bare module name is also recorded for the implicit default module version. IfMODULES_COLLECTION_PIN_VERSION is set to 1, module version is always recorded even if it is the default version.

By default, only the module tags specifically set with the --tagoption or resulting from a specific module state (like auto-loaded andkeep-loaded tags) are recorded in collection. IfMODULES_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 theprereq and conflict they declare.

Added in version 4.0.

savelist [-t|-l|-j] [-a] [-S|-C] [pattern...]

List collections that are currently saved under the user's collection directory. If MODULES_COLLECTION_TARGET is set, only collections 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 default. 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/-aoption is set. Stash collections can be listed with stashlistsub-command.

Added in version 4.0.

Changed in version 4.5: Option --json/-j added

Changed in version 5.2: pattern search to filter collections added

Changed in version 5.2: Options --starts-with/-S,--contains/-C and --all/-aadded

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 _default_collection. If MODULES_COLLECTION_TARGET is set, a suffix equivalent to the value of this variable will be appended to the _collection_file name.

Added in version 4.0.

saveshow [collection]

Display the content of collection. If collection 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, 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.

Added in version 4.0.

Changed in version 5.2: Display content of initial environment when collection name is__init__ or when no collection name is specified and no _default_collection exists

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.

Added in version 4.0: Prior version 4.0 module-whatis information search was performed with apropos or keyword sub-commands.

Changed in version 4.5: Option --json/-j added

Changed in version 4.6: Option --all/-a added

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 after_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.

Added in version 4.6.

Changed in version 5.1: Changes on Modules private environment variable are ignored

Changed in version 5.1: Support for tracking shell completion changes on bash, tcsh and fish shells added

Changed in version 5.4: Support for bash-eval shell mode added

show modulefile...

See display.

source [options] modulefile...

Execute modulefile into the shell environment. Once executed _modulefile_is not marked loaded in shell environment which differ from loadsub-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 modulefiles.

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

Added in version 4.0.

Changed in version 5.2: Accept modulefile specification as argument

stash [-f]

Save current environment in a stash collection thenreset to initial environment.

A collection is created only if current environment state differs from initial environment. Stash collection is named_stash-<unix_millis_timestamp>_ where <unix_millis_timestamp> is the number of milliseconds 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.

Added in version 5.2.

Changed in version 5.4: Option --force/-f added

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.

Added in version 5.2.

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.

Added in version 5.2.

stashpop [-f] [stash]

Restore stash collection then delete corresponding collection file.

stash is either a full stash collection name (i.e.,stash-<unix_millis_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.

Added in version 5.2.

Changed in version 5.4: Option --force/-f added

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.

Added in version 5.2.

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.

Added in version 5.2.

state [name]

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

Added in version 5.1.

swap [options] [modulefile1] modulefile2

See switch.

switch [options] [modulefile1] modulefile2

Switch loaded modulefile1 with modulefile2. If modulefile1 is not specified, then it is assumed to be the currently loaded module with the same root name as modulefile2.

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_modulefile_ 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 (andswitch 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 switchsub-command is defined in abort_on_error configuration option and--force option is not set.

Changed in version 4.2: Options --auto, --no-auto,--force/-f added

Changed in version 5.1: Option --tag added

Changed in version 5.4: Support for abort_on_error configuration option added

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 error, test sequence continues.

Added in version 4.0.

try-add [options] modulefile...

See try-load.

Added in version 4.8.

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_modulefile_ 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 sequentially 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 inabort_on_error configuration option and --force option is not set.

Added in version 4.8.

Changed in version 5.1: Option --tag added

Changed in version 5.4: Support for abort_on_error configuration option added

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 error, unload sequence continues: unloaded modules prior the evaluation 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 inabort_on_error configuration option and --force option is not set.

Changed in version 4.2: Options --auto, --no-auto,--force/-f added

Changed in version 5.4: Support for abort_on_error configuration option added

unuse directory...

Remove one or more directories from the MODULEPATH environment variable.

If module unuse is called during a modulefile evaluation, the reference 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. Whenmodule 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 separated by colon character, each path is treated separately.

Changed in version 5.0: directory is removed whatever its reference counter value ifmodule unuse is called from the command-line or within an initialization modulefile script

Changed in version 5.0: Accept several modulepaths passed as a single string

use [-a|--append] directory...

Prepend one or more directories to the MODULEPATH environment variable. The --append flag will append the directory toMODULEPATH.

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 reference counter environment variable__MODULES_SHARE_MODULEPATH is also set to increase the number of times directory has been added toMODULEPATH. Reference counter is not updated whenmodule 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.

Changed in version 5.0: Accept non-existent modulepath

Changed in version 5.0: Reference counter value of directory is not anymore increased ifmodule use is called from the command-line or within an initialization modulefile script

whatis [-a] [-j] [pattern...]

Display the information set up by the module-whatis commands inside_modulefiles_ matching pattern. pattern may contain wildcard characters. If no pattern is specified, all module-whatis lines will be shown.

Changed in version 4.5: Option --json/-j added

Changed in version 4.6: Option --all/-a added

Changed in version 5.3: pattern may include variant specification or extra specifier to filter results

Modulefiles

modulefiles are written in the Tool Command Language (Tcl) and are interpreted 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 environment variables return to their prior state.

Advanced module version specifiers

When the advanced module version specifiers mechanism is enabled (seeMODULES_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.3syntax will select module foo/1.2.3
a list of versions with the @version1,version2,... syntax, for instancefoo@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:version2 syntaxes, for instance foo@1.2: will select all versions of module foo greater than or equal to 1.2, foo@:1.3will select all versions less than or equal to 1.3 and foo@1.2:1.3matches all versions between 1.2 and 1.3 including 1.2 and1.3 versions

Advanced specification of single version or list of versions may benefit from the activation of the extended default mechanism (seeMODULES_EXTENDED_DEFAULT) to use an abbreviated notation like @1to 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 instance 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 instancefoo@:1.2,1.4:1.6,1.8:. Such specification helps to exclude specific versions, like versions 1.3 and 1.7 in previous example.

If the implicit default mechanism is also enabled (seeMODULES_IMPLICIT_DEFAULT), a default and latest symbolic versions are automatically 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 themod@latest (or mod/latest) syntax ensures highest available version will be selected.

The symbolic version loaded may be used over loaded module name to designate 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.

Added in version 4.4.

Changed in version 4.8: Use of version range is allowed in version list

Variants

After the module name, variants can be specified. Module variants are alternative evaluation of the same modulefile. A variant is specified by associating a value to its name. This specification is then transmitted to the evaluating modulefile which instantiates the variant in theModuleVariant array variable when reaching the variantmodulefile command declaring this variant.

Variant can be specified with the name=value syntax where name is the declared variant name and value, the value this variant is set to when evaluating 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 defined appended to another specification word (e.g., the module name, version 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 oroff to disable the variant.

Shortcuts may be used to abbreviate variant specification. Thevariant_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 thefoo=value syntax.

Variant name should only be composed of characters part of theA-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).

Added in version 4.8.

Changed in version 5.5: Stricter variant name naming rule adopted

Changed in version 5.5: + and ~ characters are allowed in module name or version if not followed by a valid variant name

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 behaviors.

Module tags may be inherited from the module state set by a modulefile command 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 themodule-forbid command and thus this module cannot be loaded.
hidden: module has been set hidden through the use of themodule-hide command and thus it is not reported by default among the result of an avail sub-command.
hidden-loaded: module has been set hidden once loaded through the use of the module-hide --hidden-loaded command thus it is not reported bu default 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.

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

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, module 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 andtry-load sub-commands and on always-load,depends-on, module, prereq, prereq-all andprereq-any modulefile commands. In case the designated module is already loaded, the additional tags are added to the list of tags already applied to this module.

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

along the module name, all tags set within angle brackets, each tag separated 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 (seeMODULES_COLORS)

When an abbreviated string is associated to a tag name (seeMODULES_TAG_ABBREV), this abbreviation is used to report tag along the module 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 abbreviation 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 graphical 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 theMODULES_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.

Added in version 4.7.

Changed in version 5.1: Tag keep-loaded added

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 thesuper-sticky module tag with the module-tagmodulefile 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 super-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 orreset sub-commands fully set the environment in target collection or initial state. Super-sticky modules still cannot be unloaded withrestore and reset sub-commands.

Added in version 4.7:

Changed in version 5.2: Unload sticky modules when restoring a collection or resetting to the initial environment

Module variants

Module variants are alternative evaluation of the same modulefile. A variant is specified by associating a value to its name when designating module. Variant specification relies on the Advanced module version specifiersmechanism.

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 instance 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 evaluation, 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 requirements or produce different environment variable setup.

Variants are interpreted in contexts where modulefiles are evaluated. Variants specified on module designation are ignored by theis-avail or path sub-commands. On search sub-commands (avail, 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 declaring 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, theExtra 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 barvariant with value1 and value2 as available values. On a module selection context, 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 abar 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 onlist sub-command results. They are also reported on availsub-command 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 thename=on,off syntax on avail sub-command. When a shortcut character is defined for a variant (see MODULES_VARIANT_SHORTCUT) it is reported with the <shortcut>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 variant are set as JSON Boolean. Other values are set as JSON strings. Variant shortcut and color rendering do not apply on JSON output.

Added in version 4.8.

Changed in version 5.3: Variants specified in avail, whatis orpaths search query interpreted to filter results

Changed in version 5.4: Multiple values may be set on one variant search criterion to select modules providing any of these variant values

Changed in version 5.5: not: prefix for variant search criterion added to select modules not matching specified variant values

Collections

Collections describe a sequence of module use thenmodule load commands that are interpreted bymodulecmd.tcl to set the user environment as described 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 default collections are saved under the $HOME/.module directory.

$ module list Currently Loaded Modulefiles:

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 saveshowsub-command. Note that in the above example, bare module name is recorded forfoo modulefile as loaded version is the implicit default. Loaded version recording can be enforced by enabling collection_pin_versionconfiguration 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 restoresub-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:

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:
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 reloaded, even if is was the same module between current environment and collection.

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

$ module savelist Named collection list:

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

When no argument is provided to save, restore,saveshow or saverm sub-commands, the defaultcollection 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 restoresub-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 andrestore sub-commands assume __init__ collection when no argument provided to them.

$ module list Currently Loaded Modulefiles:

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

Initial environment state can also be restored with the resetsub-command. This sub-command behavior can be changed withreset_target_state configuration 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 thecollection_target configuration option. When set, available collections are reduced to those suffixed with target name. Which meansrestore, saveshow, savelist and savermonly find collections matching currently set target.

$ module savelist Named collection list:

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"):

bar $ ls $HOME/.module bar.mytarget foo

Collection targets help to distinguish contexts and make collection reachable 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_TARGETsection.

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 collection then initial environment is restored.

$ module list Currently Loaded Modulefiles:

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 restored 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

Added in version 4.0.

Changed in version 5.2: Initial environment state introduced

Changed in version 5.2: Stash collection introduced

Site-specific configuration

Siteconfig, the site-specific configuration script, is a way to extendmodulecmd.tcl. Siteconfig is a Tcl script. Its location is/etc/environment-modules/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 siteconfig.

An additional siteconfig script may be specified through theextra_siteconfig configuration option. TheMODULES_SITECONFIG environment variable is defined byconfig 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 previously defined variables and procedures. Sites may deploy their own Tcl code in siteconfig to adapt modulecmd.tcl to their specific needs. Thetrace 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 whatwhat whatmore] } } }

Siteconfig hook variables

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

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_varsprior the evaluation of the next modulefile.

set modulefile_extra_vars {myvar 1 othervar {some text}}

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

Added in version 5.2.

List of command and associated local procedure to setup in modulefile evaluation context. These commands can be called from the modulefile to execute associated procedure. In case a modulefile changes the definition of such command, its definition is bound again on the procedure defined inmodulefile_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 themycmd and othercmd commands in the modulefile evaluation context and bind them respectively to the mycmd and anotherproc procedures defined in siteconfig script.

Added in version 5.2.

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 variable, 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 themyvar and othervar variables in the modulerc evaluation context with respectively 1 and some text as value.

Added in version 5.2.

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 definition of such command, its definition is bound again on the procedure defined inmodulerc_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 themycmd and othercmd commands in the modulerc evaluation context and bind them respectively to the mycmd and anotherproc procedures defined in siteconfig script.

Added in version 5.2.

Added in version 4.1.

Changed in version 4.3: Additional site-specific configuration script introduced

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-modulefiles 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 especially 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 number 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 content 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, 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 autoinitsub-command after checking it is not set. It ensures no nested initialization of Modules occur. At the end of the processing of the autoinitsub-command, __MODULES_AUTOINIT_INPROGRESS is unset.

Added in version 5.0.

__MODULES_LMALTNAME

A colon separated list of the alternative names set throughmodule-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 theas| 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 _modulefiles_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-loadedor 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.

Added in version 4.2.

Changed in version 5.0: Variable renamed from MODULES_LMALTNAME to __MODULES_LMALTNAME

__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 modulefiles and conflicting modulefile names are separated by the ampersand character.

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

Added in version 4.2.

Changed in version 5.0: Variable renamed from MODULES_LMCONFLICT to__MODULES_LMCONFLICT

A colon separated list of the tags corresponding to all loaded _modulefiles_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.

Added in version 5.1.

__MODULES_LMINIT

A colon separated list describing the modulepaths that have been enabled and the modulefiles that have been loaded with their tags during 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 initialization.

This initial environment state can then be restored with resetsub-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 withsaveshow sub-command when __init__ collection name is specified or when no collection name is specified and no default collection exists.

Added in version 5.2.

__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 modulefiles and pre-required modulefile names are separated by the ampersand character. When a prereq statement is composed of multiple modulefiles, these modulefile 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 when a pre-required module is asked for unload afterward.

Added in version 4.2.

Changed in version 5.0: Variable renamed from MODULES_LMPREREQ to __MODULES_LMPREREQ

__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 declares aprereq 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 statement is composed of multiple modulefiles or multiple specific modulepaths, 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.

Added in version 5.5.

__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.

Added in version 5.2.

__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 eachsource-sh statement call and corresponding result achieved in modulefile. The loaded modulefile name and each source-sh statement description are separated by the ampersand character. The source-shstatement 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 eachsource-sh command when loading the modulefile. In order to reverse these modulefile commands when modulefile is unloaded to undo the environment changes.

Added in version 4.6.

Changed in version 5.0: Variable renamed from MODULES_LMSOURCESH to__MODULES_LMSOURCESH

__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 ampersand character. Tag name and module specifications on which it applies 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.

Added in version 5.4.

__MODULES_LMTAG

A colon separated list of the tags corresponding to all loaded _modulefiles_that have been set through module-tag statements or from other modulefile statements like module-forbid (that may apply thenearly-forbidden tag in specific situation) (see Module tags section). Each element in this list starts by the name of the loaded _modulefile_followed by all 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 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.

Added in version 4.7.

Changed in version 5.0: Variable renamed from MODULES_LMTAG to __MODULES_LMTAG

__MODULES_LMVARIANT

A colon separated list of the variant instantiated through variantstatements by all loaded modulefiles (see Module variants section). Each element in this list starts by the name of the loaded _modulefile_followed by all the variant definitions set during the load of this module. The loaded modulefile and each of its variant definition are separated by the ampersand character. Each variant definition 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 _modulefiles_in order to keep environment consistent when requirements are set over a specific variant value or just to report these variant values when listing loaded modules.

Added in version 4.8.

Changed in version 5.0: Variable renamed from MODULES_LMVARIANT to __MODULES_LMVARIANT

__MODULES_PUSHENV_

Stack of saved values for <VAR> environment variable. A colon-separated list containing pairs of elements. A pair is formed by a loaded module name followed by the value set to <VAR> in this module withpushenv 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 evaluatedpushenv command, this value is associated to an empty module name to record it as a pair element in __MODULES_PUSHENV_.

Added in version 5.1.

__MODULES_QUAR_

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

Added in version 4.1.

Changed in version 5.0: Variable renamed from <VAR>_modquar to __MODULES_QUAR_<VAR>

__MODULES_QUARANTINE_SET

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

Added in version 5.0.

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 separates 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 variable, 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 variable, 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.

Added in version 4.0.

Changed in version 5.0: Variable renamed from <VAR>_modshare to __MODULES_SHARE_<VAR>

Changed in version 5.0: Elements are added to the reference counter variable only if added more than one time in the relative path-like variable

_LMFILES_

A colon separated list of the full pathname for all loaded modulefiles.

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 interpretation of modulefiles.

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

Added in version 4.0.

MODULEPATH

The path that the module command searches when looking for_modulefiles_. Typically, it is set to the main modulefiles directory,/usr/share/Modules/modulefiles, by the initialization script. MODULEPATHcan be set using module use or by the module initialization script to search group or personal modulefile directories before 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 theMODULEPATH 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 information.

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 thercfile configuration option. It can be defined with theconfig 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 behavior, apply the continue on error behavior. In this case if one modulefile evaluation fails, sequence continues with remaining modulefiles. When--force option is used, continue on error behavior applies.

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

Added in version 5.4.

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 theadvanced_version_spec configuration option. It can be defined with the config sub-command.

Added in version 4.4.

MODULES_AUTO_HANDLING

If set to 1, enable automated module handling mode. If set to 0disable automated module handling mode. Other values are ignored.

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

Conflict Unload: unload of the modulefiles declared as aconflict 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 prereqof 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 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 taggedkeep-loaded, sticky or super-sticky.
Dependent Reload: reload of the modulefiles declaring a prereqonto loaded modulefile or declaring a prereq 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-optionalprereq onto unloaded modulefile or declaring a non-optionalprereq onto a modulefile part of this unloading batch. Aprereq modulefile is considered optional if the prereqdefinition order is made of multiple 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 useless 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 super-sticky.
Dependent Reload: reload of the modulefiles declaring a conflictor an optional prereq onto either the unloaded modulefile, an unloaded dependent or an unloaded useless requirement or declaring aprereq onto a modulefile part of this reloading batch.

In case a loaded modulefile has some of its declared constraints unsatisfied (pre-required modulefile not loaded or conflicting modulefile 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 either if the requirements of this modulefile are not loaded or if a conflict is spotted with the loaded environment. Reload is attempted in any case if modulefile is tagged super-sticky or sticky and force mode is disabled. Dependent Reload module whose reload has been skipped are considered Dependent Unload module.

Conflict Unload mechanism is activated only if conflict_unloadconfiguration option is also enabled.

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

Added in version 4.2.

Changed in version 5.1: Modules with keep-loaded tag set are excluded from Useless Requirement Unload mechanism

Changed in version 5.5: Modules with sticky or super-sticky tag set are excluded from Useless Requirement Unload mechanism

Changed in version 5.5: Conflict Unload and Useless Requirement Unload mechanisms added on module load context

Changed in version 5.5: Reload of a Dependent Reload module is skipped if it is not loadable

Changed in version 5.5: Reload of all Dependent Reload modules occurs after the main evaluation

MODULES_AVAIL_INDEPTH

If set to 1, enable in depth search results for availsub-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 results. When disabled these modulefiles and directories contained in matching directories are excluded.

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

Added in version 4.3.

MODULES_AVAIL_OUTPUT

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

Accepted elements that can be set in value list are:

alias: module aliases.
dirwsym: directories associated with symbolic versions.
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 available modules.
variantifspec: like variant but only if a variant has been specified in search query.

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 theavail_output configuration option. It can be defined with the config sub-command. The --output/-o command line switches override this environment variable.

Added in version 4.7.

Changed in version 5.3: Elements variant and variantifspec added

Changed in version 5.3.1: Element indesym added

MODULES_AVAIL_TERSE_OUTPUT

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

See MODULES_AVAIL_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 theavail_terse_output configuration option. It can be defined with the config sub-command. The --output/-ocommand line switches override this environment variable.

Added in version 4.7.

Changed in version 5.3: Elements variant and variantifspec added

MODULES_CACHE_BUFFER_BYTES

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

Added in version 5.3.

MODULES_CACHE_EXPIRY_SECS

Number of seconds a cache file is considered valid after being generated. 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 (equivalent to one year duration).

Added in version 5.3.

MODULES_CMD

The location of the active module command script.

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

Added in version 4.1.

MODULES_COLLECTION_PIN_VERSION

If set to 1, register exact version number of modulefiles when saving 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 thecollection_pin_version configuration option. It can be defined with the config sub-command.

Added in version 4.1.

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 --tagoption and tags resulting from specific module states (like auto-loadedand keep-loaded tags) are recorded in collection. Note that thenearly-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 thecollection_pin_tag configuration option. It can be defined with the config sub-command.

Added in version 5.1.

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 different 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 collection filename with.$MODULES_COLLECTION_TARGET. The collection target 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 thecollection_target configuration option. It can be defined with the config sub-command.

Added in version 4.0.

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 standard error output channel is attached to a terminal.

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

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

Added in version 4.3.

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 follows the same syntax thanLS_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 version (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 graphical rendering. Each basic tag has by default a key set in the color palette, based on its abbreviated string: auto-loaded (aL), forbidden (F), hidden and hidden-loaded (H), loaded (L), nearly-forbidden (nF), sticky (S), super-sticky (sS) and keep-loaded (kL).

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 sequence (\33[...m). Common values to concatenate include 1 for bold, 4 for underline, 30 to37 for foreground colors and 90 to 97 for 16-color mode foreground colors. See also https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Rendition)_parametersfor 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 ifMODULES_COLORS is defined empty, no output will be colored at all.

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

Added in version 4.3.

Changed in version 4.6: Output item for trace information (tr) added

Changed in version 4.7: Output items for module tags auto-loaded (aL), forbidden (F), hidden and hidden-loaded (H), loaded (L), nearly-forbidden (nF), sticky (S) and super-sticky (sS) added

Changed in version 4.8: Output item for module variant (va) added

Changed in version 5.1: Output item for keep-loaded module tag (kL) added

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 unload 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 theconflict_unload configuration option. It can be defined with the config sub-command.

Added in version 5.5.

MODULES_EDITOR

Text editor command name or path for use to open modulefile through theedit sub-command.

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

Text editor could also be defined through the VISUAL orEDITOR environment variables. These environment variables are overridden by MODULES_EDITOR.

Added in version 4.8.

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 modulefilemod/1.2.3.

In case multiple modulefiles match the specified module version and a single module has to be selected, the explicitly set default version is returned if it is part of matching modulefiles. Otherwise the implicit default among matching modulefiles is returned if defined (seeMODULES_IMPLICIT_DEFAULT section)

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

Added in version 4.4.

MODULES_FAMILY_

Module name minus version that provides for the name family in currently 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 thebar family, the MODULES_FAMILY_BARwill be set to the foo value.

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

Added in version 5.1.

MODULES_HIDE_AUTO_LOADED

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

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

Added in version 5.5.

MODULES_ICASE

When module specification are passed as argument to module sub-commands or modulefile Tcl commands, defines the case sensitiveness to apply to match them. When MODULES_ICASE is set to never, a case sensitive match is applied in any cases. When set to search, a case insensitive match is applied to the avail, list, whatis,paths and savelist sub-commands. When set to always, a case insensitive 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 theicase configuration option. It can be defined with theconfig sub-command. The --icase/-i command line switches, which correspond to the always mode, override this environment variable.

Added in version 4.4.

Changed in version 5.1: Search mode applied to list sub-command

Changed in version 5.2: Search mode applied to savelist sub-command

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 theignore_cache configuration option. It can be defined with theconfig sub-command. The --ignore-cache command line switch overrides this environment variable.

Added in version 5.3.

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 theignore_user_rc configuration option. It can be defined with theconfig sub-command. The --ignore-user-rc command line switch overrides this environment variable.

Added in version 5.3.

MODULES_IMPLICIT_DEFAULT

Defines (if set to 1) or not (if set to 0) an implicit default version for modules without a default version explicitly defined (seeLocating 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 addition 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 collection-specified order.
automatically loaded by automated module handling mechanisms (seeMODULES_AUTO_HANDLING section) when declared as module requirement, with prereq or module loadmodulefile 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 theimplicit_default configuration option. It can be defined with theconfig sub-command. This environment variable is ignored ifimplicit_default has been declared locked inlocked_configs configuration option.

Added in version 4.3.

MODULES_IMPLICIT_REQUIREMENT

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

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

Added in version 4.7.

MODULES_LIST_OUTPUT

A colon separated list of the elements to report in addition to module 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.
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 thelist_output configuration option. It can be defined with theconfig sub-command. The --output/-o command line switches override this environment variable.

Added in version 4.7.

Changed in version 4.8: Element variant added

Changed in version 5.4: Elements alias and indesym added

MODULES_LIST_TERSE_OUTPUT

A colon separated list of the elements to report in addition to module 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 thelist_terse_output configuration option. It can be defined with theconfig sub-command. The --output/-o command line switches override this environment variable.

Added in version 4.7.

Changed in version 4.8: Element variant added

Changed in version 5.4: Elements alias and indesym added

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 thelogged_events configuration option. It can be defined with theconfig sub-command. This environment variable is ignored iflogged_events has been declared locked inlocked_configs configuration option.

Added in version 5.5.

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 thelogger configuration option. It can be defined with theconfig sub-command. This environment variable is ignored iflogger has been declared locked in locked_configsconfiguration option.

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

Added in version 5.5.

MODULES_MCOOKIE_CHECK

If set to eval, the Modules magic cookie (i.e., #%Modulefile signature) 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 walking 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 ofmodulecmd.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 inalways mode.

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

Added in version 5.1.

MODULES_MCOOKIE_VERSION_CHECK

If set to 1, the version set in the Modules magic cookie in modulefile is checked against the current version of modulecmd.tcl to determine if the modulefile can be evaluated.

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

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

Added in version 4.7.

MODULES_ML

If set to 1, define ml command when initializing Modules (seePackage Initialization section). If set to 0, ml command is not defined.

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

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

Added in version 4.5.

MODULES_NEARLY_FORBIDDEN_DAYS

Number of days a module is considered nearly forbidden prior reaching 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 thenearly_forbidden_days configuration option. It can be defined with the config sub-command.

Added in version 4.6.

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

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

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

Pager is never launched if modulecmd.tcl program is run for scripting language rather shells.

Added in version 4.1.

Changed in version 5.5: No pager when modulecmd.tcl is run for scripting languages

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 modify a protected environment variable, a warning message is emitted and modification is ignored.

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

Added in version 5.2.

MODULES_QUARANTINE_SUPPORT

If set to 1, produces the shell code for quarantine mechanism when theautoinit 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 themodulecmd.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 thequarantine_support configuration should be set to 1 in theinitrc configuration file.

Generated code for quarantine mechanism sets the__MODULES_QUARANTINE_SET environment variable when calling themodulecmd.tcl script to make it restore the environment variable put in quarantine.

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

Added in version 5.0.

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 theredirect_output configuration option. It can be defined with the config sub-command. The --redirect and--no-redirect command line switches override this environment variable.

Added in version 5.1.

MODULES_RESET_TARGET_STATE

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

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

Added in version 5.2.

MODULES_RUN_QUARANTINE

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

If the quarantine mechanism has been included in module shell function (see MODULES_QUARANTINE_SUPPORT), each variable found inMODULES_RUN_QUARANTINE will have its value emptied or set to the value of the corresponding MODULES_RUNENV_ variable when defining modulecmd.tcl run-time environment.

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

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

Added in version 4.1.

MODULES_RUNENV_

Value to set to environment variable <VAR> formodulecmd.tcl run-time execution if <VAR> is referred inMODULES_RUN_QUARANTINE.

Added in version 4.1.

MODULES_SEARCH_MATCH

When searching for modules with avail sub-command, defines the way query string should match against available module names. Withstarts_with value, returned modules are those whose name begins by search query string. When set to contains, any modules whose fully qualified name contains search query string are returned.

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

Added in version 4.3.

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 andBASH_ENV environment variable to the Modules bourne shell initialization script. If set to 0, shell startup file is not defined.

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

To enable shell startup file, MODULES_SET_SHELL_STARTUP should be set to 1 prior Modules initialization or the set_shell_startupconfiguration option should be set to 1 in the initrcconfiguration file.

Added in version 4.3.

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-functionsdirectory where the ksh initialization script for module command is located. It enables for the listed shells to get module function defined 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 theshells_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_fpathconfiguration option should be set to the list of these shells in theinitrc configuration file.

Added in version 4.7.

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 modulecommand 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 thesilent_shell_debug configuration option. It can be defined with theconfig sub-command.

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

Added in version 4.1.

MODULES_SITECONFIG

Location of a site-specific configuration script to source intomodulecmd.tcl. See Site-specific configuration section for details.

This environment variable value supersedes the default value set in theextra_siteconfig configuration option. It can be defined with theconfig sub-command. This environment variable is ignored ifextra_siteconfig has been declared locked inlocked_configs configuration option.

Added in version 4.3.

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 thesource_cache configuration option. It can be defined with theconfig sub-command.

Added in version 5.4.

MODULES_STICKY_PURGE

When unloading a sticky or super-sticky module during a modulepurge, raise an error or emit a warning message or besilent.

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

Added in version 5.4.

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=abbrev).

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

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

Added in version 4.7.

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 inMODULES_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 thetag_color_name configuration option. It can be defined with theconfig sub-command.

Added in version 4.7.

MODULES_TCL_LINTER

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

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

Added in version 5.2.

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 defined with theMODULES_COLORS variable. Accepted values are dark andlight.

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

Added in version 4.3.

MODULES_TERM_WIDTH

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

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

Added in version 4.7.

MODULES_UNIQUE_NAME_LOADED

If set to 1, allows only one module loaded per module name. A conflict 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 theunique_name_loaded configuration option. It can be defined with the config sub-command.

Added in version 5.4.

MODULES_UNLOAD_MATCH_ORDER

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

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

Added in version 4.3.

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 character (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 (i.e., [-+~/@=a-zA-Z0-9]).

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

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

Added in version 4.8.

MODULES_VERBOSITY

Defines the verbosity level of the module command. Available verbosity 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 informational messages.
normal: turn on informational messages, like a report of the additional module evaluations triggered by loading or unloading modules, aborted evaluation issues or a report of each module evaluation occurring during arestore 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 hidden-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 printing debug messages.

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

Added in version 4.3.

Changed in version 4.6: Verbosity levels trace and debug2 added

Changed in version 4.7: Verbosity level verbose2 added

MODULES_WA_277

If set to 1 prior to Modules package initialization, enables workaround for Tcsh history issue (see https://github.com/cea-hpc/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 history mechanism issue. However the alternative definition of the_module_ alias weakens shell evaluation of the code produced by modulefiles. 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 thewa_277 configuration option. It can be defined with theconfig sub-command.

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

Added in version 4.3.

MODULESHOME

The location of the main Modules package file directory containing module command initialization scripts, the executable program modulecmd.tcl, and a directory containing a collection of main modulefiles.

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

FILES

/usr/share/Modules

The MODULESHOME directory.

/etc/environment-modules/initrc

The configuration file evaluated by modulecmd.tcl when it initializes to enable the default modulepaths, load the default modules and setmodule command configuration.

initrc is a modulefile so it is written as a Tcl script and defines modulepaths to enable with module use, modules to load with module load and configuration to apply withmodule 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 evaluated after the modulespath configuration file. See thePackage Initialization section for details.

/etc/environment-modules/modulespath

The configuration file evaluated by modulecmd.tcl when it initializes to enable the default modulepaths. This file contains the list of modulepaths 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 thePackage Initialization section for details.

/etc/environment-modules/siteconfig.tcl

The site-specific configuration script of modulecmd.tcl. An additional configuration script could be defined using theMODULES_SITECONFIG environment variable. See Site-specific configuration for detailed information.

/etc/environment-modules/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/share/Modules/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/share/Modules/libexec/modulecmd.tcl

The modulefile interpreter that gets executed upon each invocation of module.

/usr/share/Modules/init/<shell>

The Modules package initialization file sourced into the user's environment.

module — Modules documentation (original) (raw)

SYNOPSIS

DESCRIPTION

Package Initialization

Examples of initialization

Modulecmd startup

Command line switches

Module Sub-Commands

Modulefiles

Advanced module version specifiers

Version specifiers

Variants

Module tags

Sticky modules

Module variants

Collections

$ module config collection_pin_version 1 $ module save foo $ module saveshow foo

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

Initial environment

$ module saveshow init

Collection targets

Stash collections

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

Site-specific configuration

Hooks

code to run right before each modulefile evaluation

Siteconfig hook variables

Module cache

EXIT STATUS

ENVIRONMENT

FILES

SEE ALSO