| MODULE(1) | Modules | MODULE(1) |
module - command interface to the Modules package
module [switches] [sub-command [sub-command-args]]
module is a user interface to the Modules package. The Modules package provides for the dynamic modification of the user's environment via modulefiles.
Each modulefile contains the information needed to configure the shell for an application. Once the Modules package is initialized, the environment can be modified on a per-module basis using the module command which interprets modulefiles. Typically modulefiles instruct the module command to alter or set shell environment variables such as PATH, MANPATH, etc. Modulefiles may be shared by many users on a system and users may have their own 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.
The Modules package and the module command are initialized when a shell-specific initialization script is sourced into the shell. The script executes the autoinit sub-command of the modulecmd.tcl program located in /usr/lib/x86_64-linux-gnu for the corresponding shell. The output of this execution is evaluated by shell which creates the module command as either an alias or function and creates Modules environment variables.
During this initialization process, if the Modules environment is found undefined (when both MODULEPATH and LOADEDMODULES are found either unset or empty), the modulespath and initrc configuration 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.tcl program and has the shell evaluate the command's output. The first argument to modulecmd.tcl specifies the type of shell.
The initialization scripts are kept in /usr/share/modules/init/<shell> where <shell> 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 the autoinit 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.
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 ...
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", "...")
Bourne Shell (sh) (and derivatives) with autoinit sub-command:
eval "$(/usr/lib/x86_64-linux-gnu/modulecmd.tcl sh autoinit)"
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:
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 of modulecmd.tcl will not be interpreted and an error is reported. Such error does not abort the whole module evaluation. If the mcookie_version_check configuration is disabled the version number set is not checked.
NOTE:
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:
On load, ml, mod-to-sh, purge, reload, switch, try-load and unload sub-commands applies continue on error behavior when an error occurs even if abort_on_error option is enabled.
On ml, purge, reload, reset, restore, stash, stashpop, switch and unload sub-commands, unloads modulefile anyway even if an evaluation error occurs.
On clear sub-command, skip the confirmation dialog and proceed.
On purge sub-command also unload sticky modules and modulefiles that are depended by non-unloadable modules.
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.
See also MODULES_AVAIL_OUTPUT and MODULES_LIST_OUTPUT.
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.
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 modulerc section.
When colored output is enabled and a specific graphical rendition is defined for module default version, the default symbol is omitted and instead the defined graphical rendition is applied to the 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 and MODULES_COLORS sections for details on colored output.
Module tags applying to the available modulefiles returned by the avail sub-command are reported along the module name they are 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). The Extra 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, the Extra 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.
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.
See Module cache section for more details on module cache mechanism.
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, current modulecmd.tcl state and Modules-related environment variables are reported in addition to currently set modulecmd.tcl options.
Existing option names are:
This configuration option can be changed at installation time with --with-abort-on-error option. The MODULES_ABORT_ON_ERROR environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_ABORT_ON_ERROR description for details.
Default value is 1. It can be changed at installation time with --disable-advanced-version-spec option. The MODULES_ADVANCED_VERSION_SPEC environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_ADVANCED_VERSION_SPEC description for details.
Default value is 1. It can be changed at installation time with --disable-auto-handling option. The MODULES_AUTO_HANDLING environment variable is defined by config sub-command when changing this configuration option from its default value. The --auto and --no-auto command line switches change the value of this configuration option. See MODULES_AUTO_HANDLING description for details.
Default value is 1. It can be changed at installation time with --disable-avail-indepth option. The MODULES_AVAIL_INDEPTH environment variable is defined by config sub-command when changing this configuration option from its default value. The --indepth and --no-indepth command line switches change the value of this configuration option. See MODULES_AVAIL_INDEPTH description for details.
Default value is modulepath:alias:dirwsym:sym:tag:key. It can be changed at installation time with --with-avail-output option. The MODULES_AVAIL_OUTPUT environment variable is defined by config sub-command when changing this configuration option from its default value. The --output/-o command line switches change the value of this configuration option. See MODULES_AVAIL_OUTPUT description for details.
Default value is modulepath:alias:dirwsym:sym:tag. It can be changed at installation time with --with-avail-terse-output option. The MODULES_AVAIL_TERSE_OUTPUT environment variable is defined by config sub-command when changing this configuration option from its default value. The --output/-o command line switches change the value of this configuration option. See MODULES_AVAIL_TERSE_OUTPUT description for details.
Default value is 32768. Values between 4096 and 1000000 are accepted. The MODULES_CACHE_BUFFER_BYTES environment variable is defined by config sub-command when changing this configuration option from its default value.
Default value is 0. Values between 0 and 31536000 are accepted. The MODULES_CACHE_EXPIRY_SECS environment variable is defined by config sub-command when changing this configuration option from its default value.
Default value is 0. The MODULES_COLLECTION_PIN_VERSION environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_COLLECTION_PIN_VERSION description for details.
Default value is 0. The MODULES_COLLECTION_PIN_TAG environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_COLLECTION_PIN_TAG description for details.
This configuration option is unset by default. The MODULES_COLLECTION_TARGET environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_COLLECTION_TARGET description for details.
Default value is auto. It can be changed at installation time with --disable-color option. The MODULES_COLOR environment variable is defined by config sub-command when changing this configuration option from its default value. The --color command line switches changes the value of this configuration option. See MODULES_COLOR description for details.
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_COLORS environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_COLORS description for details.
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 MODULECONTACT description for details.
Default value is 1. It can be changed at installation time with --disable-extended-default option. The MODULES_EXTENDED_DEFAULT environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_EXTENDED_DEFAULT description for details.
Default value is vi. It can be changed at installation time with --with-editor option. The MODULES_EDITOR environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_EDITOR description for details.
This configuration option is unset by default. The MODULES_SITECONFIG environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_SITECONFIG description for details.
Default value is /usr/share/modules. It can be changed at installation time with --prefix or --with-moduleshome options. The MODULESHOME environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULESHOME description for details.
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.
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.
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.
Default value is CVS RCS SCCS .svn .git .SYNC .sos. The value of this option cannot be altered.
Default value is 1. It can be changed at installation time with --disable-implicit-default option. The MODULES_IMPLICIT_DEFAULT environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_IMPLICIT_DEFAULT description for details.
Default value is 1. It can be changed at installation time with --disable-implicit-requirement option. The MODULES_IMPLICIT_REQUIREMENT environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_IMPLICIT_REQUIREMENT description for details.
Default value is header:idx:variant:sym:tag:key. It can be changed at installation time with --with-list-output option. The MODULES_LIST_OUTPUT environment variable is defined by config sub-command when changing this configuration option from its default value. The --output/-o command line switches change the value of this configuration option. See MODULES_LIST_OUTPUT description for details.
Default value is header. It can be changed at installation time with --with-list-terse-output option. The MODULES_LIST_TERSE_OUTPUT environment variable is defined by config sub-command when changing this configuration option from its default value. The --output/-o command line switches change the value of this configuration option. See MODULES_LIST_TERSE_OUTPUT description for details.
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.
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. See MODULES_MCOOKIE_CHECK description for details.
Default value is 1. It can be changed at installation time with --disable-mcookie-version-check option. The MODULES_MCOOKIE_VERSION_CHECK environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_MCOOKIE_VERSION_CHECK description for details.
Default value is 1. It can be changed at installation time with --disable-ml option. The MODULES_ML environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_ML description for details.
Default value is 14. It can be changed at installation time with --with-nearly-forbidden-days option. The MODULES_NEARLY_FORBIDDEN_DAYS environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_NEARLY_FORBIDDEN_DAYS description for details.
Default value is less -eFKRX. It can be changed at installation time with --with-pager and --with-pager-opts options. The MODULES_PAGER environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_PAGER description for details.
This configuration option is unset by default. The MODULES_PROTECTED_ENVVARS environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_PROTECTED_ENVVARS description for details.
Default value is 0. It can be changed at installation time with --enable-quarantine-support option. The MODULES_QUARANTINE_SUPPORT environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_QUARANTINE_SUPPORT description for details.
This configuration option is unset by default. The MODULERCFILE environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULERCFILE description for details.
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.
Default value is __init__. The MODULES_RESET_TARGET_STATE environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_RESET_TARGET_STATE description for details.
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.
Default value is starts_with. It can be changed at installation time with --with-search-match option. The MODULES_SEARCH_MATCH environment variable is defined by config sub-command when changing this configuration option from its default value. The --contains and --starts-with command line switches change the value of this configuration option. See MODULES_SEARCH_MATCH description for details.
Default value is 0. It can be changed at installation time with --enable-set-shell-startup option. The MODULES_SET_SHELL_STARTUP environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_SET_SHELL_STARTUP description for details.
This configuration option is set to an empty value by default. The MODULES_SHELLS_WITH_KSH_FPATH environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_SHELLS_WITH_KSH_FPATH description for details.
Default value is 0. It can be changed at installation time with --enable-silent-shell-debug-support option. The MODULES_SILENT_SHELL_DEBUG environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_SILENT_SHELL_DEBUG description 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.
Default value is 0. It can be changed at installation time with --enable-source-cache option. The MODULES_SOURCE_CACHE environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_SOURCE_CACHE description for details.
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 by config sub-command when changing this configuration option from its default value. See MODULES_STICKY_PURGE description for details.
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-abbrev option. The MODULES_TAG_ABBREV environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_TAG_ABBREV description for details.
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 by config sub-command when changing this configuration option from its default value. See MODULES_TAG_COLOR_NAME description for details.
Default value is @libdir@/libtclenvmodules.so. It can be changed at installation time with --prefix or --libdir options. The value of this option cannot be altered.
Default value is nagelfar.tcl. It can be changed at installation time with --with-tcl-linter and --with-tcl-linter-opts options. The MODULES_TCL_LINTER environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_TCL_LINTER description for details.
Default value is dark. It can be changed at installation time with --with-terminal-background option. The MODULES_TERM_BACKGROUND environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_TERM_BACKGROUND description for details.
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.
Default value is 0. It can be changed at installation time with --enable-unique-name-loaded option. The MODULES_UNIQUE_NAME_LOADED environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_UNIQUE_NAME_LOADED description for details.
Default value is returnlast. It can be changed at installation time with --with-unload-match-order option. The MODULES_UNLOAD_MATCH_ORDER environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_UNLOAD_MATCH_ORDER description for details.
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 by config sub-command when changing this configuration option from its default value. See MODULES_VARIANT_SHORTCUT description for details.
Default value is normal. It can be changed at installation time with --with-verbosity option. The MODULES_VERBOSITY environment variable is defined by config sub-command when changing this configuration option from its default value. The --debug/-D, --silent/-s, --trace/-T and --verbose/-v command line switches change the value of this configuration option. See MODULES_VERBOSITY description for details.
Default value is 0. It can be changed at installation time with --enable-wa-277 option. The MODULES_WA_277 environment variable is defined by config sub-command when changing this configuration option from its default value. See MODULES_WA_277 description for details.
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.
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).
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, help sequence continues.
C Shell
TENEX C Shell
Bourne and Korn Shells
GNU Bourne Again Shell
Z Shell
Friendly Interactive Shell
If a module load line is found in any of these files, the modulefiles are appended to any existing list of modulefiles. The module load line must be located in at least one of the files listed above for any of the init sub-commands to work properly. If the module load line is found in multiple shell initialization files, all of the lines are changed.
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).
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).
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).
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/-a option 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).
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).
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, loaded modules are included in results only if they match it. pattern may be a bare variant specification without mention of a module name.
load command accepts the following options:
Once loaded, the loaded module tag is associated to the loaded module. If module has been automatically loaded by another module, the auto-loaded tag is associated instead (see Module tags section).
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 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 in abort_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.
load-any command accepts the following options:
Once loaded, the loaded module tag is associated to the loaded module. If module has been automatically loaded by another module, the auto-loaded tag is associated instead (see Module tags section).
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).
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.
mod-to-sh command accepts the following options:
An attempt to load modulefile is made to get its environment changes. This evaluation does not change the current shell environment. Like for load sub-command, no evaluation occurs if modulefile is found loaded in current environment.
Changes made on environment variable intended for Modules private use (e.g., LOADEDMODULES, _LMFILES_, __MODULES_*) are ignored.
Shell could be any shell name supported by modulecmd.tcl.
Produced shell code is returned on the message output channel by modulecmd.tcl. Thus it is not rendered in current environment by the module shell function.
mod-to-sh automatically set verbosity to the silent mode, to avoid messages to mix with the produced shell code. Verbosity is not changed if set to the trace mode or any higher debugging level.
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, mod-to-sh sequence continues: environment change from modules evaluated prior the error are preserved and sequence is resumed with the evaluation of remaining modulefile in list. Conversely, mod-to-sh sequence is aborted and changes from already evaluated modules are withdrawn if mod-to-sh sub-command is defined in abort_on_error configuration option and --force option is not set.
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).
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).
If pattern contains variant specification or Extra specifier, the Extra 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.
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.
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 if purge sub-command is defined in abort_on_error configuration option and --force option is not set.
Loaded modules are evaluated in refresh mode following their load order. In this evaluation mode only the complete, set-alias, set-function and puts modulefile commands will produce environment changes. Other modulefile commands that produce environment changes (like setenv or append-path) are ignored during a refresh evaluation as their changes should already be applied.
Only the loaded modules defining non-persistent environment changes are evaluated in refresh mode. Such loaded modules are listed in the __MODULES_LMREFRESH environment variable.
If one modulefile evaluation raises an error, refresh sequence continues: environment changes from refreshed modules prior the evaluation error are preserved and sequence is resumed with the refresh of remaining modulefiles.
No unload then load is performed and an error is returned if the loaded modulefiles have unsatisfied constraint corresponding to the prereq and conflict they declare.
When the --force option is set, unload modulefiles anyway even if an evaluation error occurs.
If one modulefile load or unload evaluation raises an error, reload sequence aborts: environment changes coming from already evaluated modulefiles are withdrawn and remaining modulefile evaluations are skipped. Conversely, if reload is removed from abort_on_error 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.
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.
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.
If collection name is __init__, initial environment state defined in __MODULES_LMINIT environment variable is restored.
When restoring a collection, the currently set MODULEPATH directory list and the currently loaded modulefiles are unused and unloaded then used and loaded to exactly match the MODULEPATH and loaded 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_default is disabled.
If one modulefile load or unload evaluation raises an error, restore sequence continues: environment changes from modules unloaded or loaded prior the evaluation error are preserved and sequence is resumed with the unload or load of remaining modulefiles.
When the --force option is set, unload modulefiles anyway even if an evaluation error occurs.
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. If MODULES_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 --tag option or resulting from a specific module state (like auto-loaded and keep-loaded tags) are recorded in collection. If MODULES_COLLECTION_PIN_TAG is set to 1, all tags are recorded in collection except nearly-forbidden tag.
No collection is recorded and an error is returned if the loaded modulefiles have unsatisfied constraint corresponding to the prereq and conflict they declare.
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/-a option is set. Stash collections can be listed with stashlist sub-command.
If collection name is __init__, initial environment content defined in __MODULES_LMINIT environment variable is displayed.
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.
source command accepts the following options:
If modulefile corresponds to a fully qualified path, this file is executed. Otherwise modulefile is searched among the available modulefiles.
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, 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.
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.
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.
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 delete.
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 display.
switch command accepts the following options:
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).
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 (and switch value is not set there) or if --force option is set, switch sequence continues. If modulefile1 is tagged super-sticky, switch sequence aborts in any case.
If load evaluation of modulefile2 raises an error, switch sequence continues: environment changes from modulefile1 unload are applied but not those from failed modulefile2 load. Conversely, whole switch sequence is aborted and unloaded modulefile1 is restored if switch sub-command is defined in abort_on_error configuration option and --force option is not set.
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, test sequence continues.
try-load command accepts the following options:
Once loaded, the loaded module tag is associated to the loaded module. If module has been automatically loaded by another module, the auto-loaded tag is associated instead (see Module tags section).
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).
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 in abort_on_error configuration option and --force option is not set.
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 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 in abort_on_error configuration option and --force option is not set.
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. When module unuse is called from the command-line or within an initialization modulefile script directory is removed whatever the reference counter value set.
If directory corresponds to the concatenation of multiple paths separated by colon character, each path is treated separately.
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 to MODULEPATH. Reference counter is not updated when module use is called from the command-line or within an initialization modulefile script.
A directory that does not exist yet can be specified as argument and then be added to MODULEPATH.
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).
If pattern contains variant specification or Extra specifier, the Extra 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.
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.
When the advanced module version specifiers mechanism is enabled (see MODULES_ADVANCED_VERSION_SPEC), the specification of modulefile passed on Modules sub-commands changes. After the module name a version constraint and variants may be added.
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:
Advanced specification of single version or list of versions may benefit from the activation of the extended default mechanism (see MODULES_EXTENDED_DEFAULT) to use an abbreviated notation like @1 to refer to more precise version numbers like 1.2.3. Range of versions on its side natively handles abbreviated versions.
In order to be specified in a range of versions or compared to a range of versions, the version major element should corresponds to a number. For 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 instance foo@: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 (see MODULES_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 the mod@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.
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 the ModuleVariant array variable when reaching the variant modulefile command declaring this variant.
Variant can be specified with the name=value syntax where name is the 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 or off to disable the variant.
Shortcuts may be used to abbreviate variant specification. The variant_shortcut configuration option associates shortcut character to variant name. With a shortcut defined, variant could be specified with the <shortcut>value syntax. For instance if character % is set as a shortcut for variant foo, the %value syntax is equivalent to the foo=value syntax.
Specific characters used in variant specification syntax cannot be used as part of the name of a module. These specific characters are +, ~, = and all characters set as variant shortcut. Exception is made for + character which could be set one or several consecutive times at the end of module name (e.g., name+ or name++).
After the module name, extra specifiers can be defined in module search context. Extra specifiers are an extra query to list available modulefiles based on their content definition. They rely on the Extra match search mechanism that collects content of available modulefiles.
Extra specifier can be set with the element:name[,name,...] syntax where element is a Tcl modulefile command and name an item defined by this command. Depending on the kind of Tcl modulefile command, name can refer to an environment variable, a shell alias, a module specification, etc.
Supported extra specifier elements are:
Each of the above supported elements corresponds to a Tcl modulefile command. load, load-any, try-load, switch and unload match corresponding module sub-commands. prereq-any is an alias on prereq and vice versa as both Tcl modulefile commands are the same. Following the same trend prereq-all is an alias on depends-on and vice versa. Regarding switch-off and switch-on elements they correspond respectively to the module to unload (if specified) and the module to load on a module switch command. switch is an alias that matches both switch-off and switch-on elements. require and incompat elements do not match module commands where --not-req option is set.
When several names are set on one element criterion (e.g., env:PATH,LD_LIBRARY_PATH), they act as an OR operation. Which means modules listed in result are those matching any of the element names defined.
When several extra specifiers are set on a module search query (e.g., env:PATH env:LD_LIBRARY_PATH), they act as an AND operation. Which means modules listed in result are those matching all extra specifiers defined.
Module specification used as name value for some extra specifier elements may leverage Advanced module version specifiers syntax. However if a module version range or list is implied, it is currently resolved to existing modules. Thus it may not match modulefile definitions targeting modules that do not exist. In addition, module aliases and symbolic versions are not resolved to their target either if set in extra specifier query or in modulefile definition.
Extra specifier can only be set in a module search context (avail, whatis and paths sub-commands). An error is raised if used on a module specification query in another context. An error is also raised if an unknown extra specifier element is defined in search query.
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:
Tags may also be associated to modules by using the module-tag modulefile command. Among tags that could be set this way, some have a special meaning:
The --tag option helps to apply additional tags to modules. It is available on load, load-any, switch and try-load sub-commands and on always-load, depends-on, module, prereq, prereq-all and prereq-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 on avail and list sub-command results and also when module's loading, unloading, refreshing or tagging evaluation is mentioned. Tags could be reported either:
When an abbreviated string is associated to a tag name (see MODULES_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 the MODULES_TAG_COLOR_NAME environment variable.
When several tags have to be rendered graphically over the same module name, each tag is rendered over a sub-part of the module name. In case more tags need to be rendered than the total number of characters in the module name, the remaining tags are graphically rendered over the tag name instead of over the module name.
When the JSON output mode is enabled (with --json), tags are reported by their name under the tags attribute. Tag abbreviation and color rendering do not apply on JSON output.
Module tags cannot be used in search query to designate a modulefile.
Modules are said sticky when they cannot be unloaded (they stick to the loaded environment). Two kind of stickiness can be distinguished:
Modules are designated sticky by associating them the sticky or the super-sticky module tag with the module-tag modulefile command.
When stickiness is defined over the generic module name (and not over a specific module version, a version list or a version range), sticky or 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 or reset sub-commands fully set the environment in target collection or initial state. Super-sticky modules still cannot be unloaded with restore and reset sub-commands.
Module variants 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 specifiers mechanism.
Once specified, variant's value is transmitted to the evaluating modulefile which instantiates the variant in the ModuleVariant array variable when reaching the variant modulefile command declaring this variant. For 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 the is-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, the Extra match search process triggers a specific scan modulefile evaluation. Variants defined in modulefile are collected during this evaluation then compared to the variants specified in search query. If there is a match, module is included in search results otherwise it is withdrawn.
When searching for available modules, if one variant is specified multiple times, matching modules are those providing all specified variant values. For instance bar=value1 bar=value2 will return modules defining a bar variant 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 provides any of these variant values. For instance bar=value1,value2 will return modules defining a bar variant with either value1 or value2 as available value.
Module variants are reported along the module they are associated to on list sub-command results. They are also reported on avail sub-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 the name=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.
Extra match search is a mechanism that evaluates available modulefiles during a module search to find those matching an extra query or to report additional information. After selecting modulefiles that match the module name and version specified in search query, these remaining modulefiles are evaluated to collect their content.
Extra match search is available on the following module search sub-commands: avail, whatis and paths.
Extra match search is triggered when:
If search query does not contain an extra query and if variant information should not be reported, no extra match search is performed. If search query does not contain any module name and version but contains an extra query or if variant information should be reported, extra match search is applied to all available modulefiles.
During this specific evaluation, modulefiles are interpreted in scan mode. This mode aims to collect the different Tcl modulefile commands used. Special care should be given when writing modulefiles to ensure they cope with such evaluation mode.
Modulefiles tagged forbidden are excluded from extra match search evaluation. Thus they are excluded from result when this mechanism is triggered.
No scan modulefile evaluation is performed if search query is only composed of tag extra specifier. Module tags are defined in modulercs thus no modulefile evaluation is required to get tags applying to a modulefile.
As extra match search implies additional modulefile evaluations, it is advised to build and use Module cache to improve search speed.
Collections describe a sequence of module use then module load commands that are interpreted by modulecmd.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: 1) foo/1.2 2) bar/2.0 3) qux/3.5 $ module save foo $ cat $HOME/.module/foo module use --append /path/to/modulefiles module load foo module load bar/2.0 module load qux/3.5
The content of a collection can also be displayed with the saveshow sub-command. Note that in the above example, bare module name is recorded for foo modulefile as loaded version is the implicit default. Loaded version recording can be enforced by enabling collection_pin_version configuration option.
$ module config collection_pin_version 1 $ module save foo $ module saveshow foo ------------------------------------------------------------------- /home/user/.module/foo: module use --append /path/to/modulefiles module load foo/1.2 module load bar/2.0 module load qux/3.5 -------------------------------------------------------------------
When a collection is activated, with the restore sub-command, module paths and loaded modules are unused or unloaded if they are not part or if they are not ordered the same way as in the collection.
$ module list Currently Loaded Modulefiles: 1) foo/1.2 2) bar/2.1 3) qux/3.5 $ module restore foo Unloading qux/3.5 Unloading bar/2.1 Loading bar/2.0 Loading qux/3.5 $ module list Currently Loaded Modulefiles: 1) foo/1.2 2) bar/2.0 3) qux/3.5
In the above example, second and third module loaded are changed. First loaded module is not changed or reloaded as it is the same module between current environment and collection. As second loaded module was different, this module and all those loaded afterward are unloaded to then load the sequence described by collection. As a result, third loaded module is 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: 1) default 2) foo $ module saverm default $ module savelist Named collection list: 1) foo
When no argument is provided to save, restore, saveshow or saverm sub-commands, the default collection is assumed.
Collection can also be specified as a full pathname:
$ module save /path/to/collections/bar $ module saveshow /path/to/collections/bar ------------------------------------------------------------------- /path/to/collections/bar: module use --append /path/to/modulefiles module load foo/1.2 module load bar/2.0 module load qux/3.5 -------------------------------------------------------------------
Initial environment state, which corresponds to modulepaths enabled and modules loaded during Modules initialization, is referred as the __init__ collection. This collection is virtual as its content is stored in the __MODULES_LMINIT and not in a file. It can be displayed with saveshow and restored with restore sub-command.
$ module saveshow __init__ ------------------------------------------------------------------- initial environment: module use --append /path/to/modulefiles module load foo/1.2 -------------------------------------------------------------------
If the default collection does not exist, saveshow and restore sub-commands assume __init__ collection when no argument provided to them.
$ module list Currently Loaded Modulefiles: 1) foo/1.2 2) bar/2.1 3) qux/3.5 $ module savelist Named collection list: 1) foo $ module restore Unloading qux/3.5 Unloading bar/2.1
Initial environment state can also be restored with the reset sub-command. This sub-command behavior can be changed with reset_target_state configuration option to choose to just purge loaded modules or to restore a specific collection.
A collection target can be defined for current environment session with the collection_target configuration option. When set, available collections are reduced to those suffixed with target name. Which means restore, saveshow, savelist and saverm only find collections matching currently set target.
$ module savelist Named collection list: 1) foo $ module config collection_target mytarget $ module savelist No named collection (for target "mytarget"). $ module restore foo ERROR: Collection foo (for target "mytarget") cannot be found
When saving a new collection, generated file is suffixed with currently set target name.
$ module save bar $ module savelist Named collection list (for target "mytarget"): 1) bar $ ls $HOME/.module bar.mytarget foo
Collection targets help to distinguish contexts and make collection 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_TARGET section.
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: 1) foo/1.2 2) qux/4.2 $ module stash Unloading qux/4.2
Specific sub-commands are available to handle stash collections: stashpop, stashlist, stashshow, stashrm and stashclear. A stash collection is 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 -------------------------------------------------------------------
Siteconfig, the site-specific configuration script, is a way to extend modulecmd.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 the extra_siteconfig configuration option. The MODULES_SITECONFIG environment variable is defined by config sub-command when setting extra_siteconfig. If it exists the extra siteconfig is sourced by modulecmd.tcl right after main siteconfig script.
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. The trace Tcl command may especially be used to define hooks that are run when entering or leaving a given procedure, or when a variable is read or written. See trace(n) man page for detailed information. The following example setup a procedure that is executed before each modulefile evaluation:
proc beforeEval {cmdstring code result op} {
# code to run right before each modulefile evaluation
}
trace add execution execute-modulefile enter beforeEval
Another possibility is to override the definition of an existing procedure by first renaming its original version then creating a new procedure that will add specific code and rely on the renamed original procedure for the rest. See rename(n) man page for details. As an example, the following code adds a new query option to the module-info modulefile command:
rename module-info __module-info
proc module-info {what {more {}}} {
switch -- $what {
platform { return myhost-$::tcl_platform(machine) }
default { return [__module-info $what $more] }
}
}
Some Tcl variables can be defined in siteconfig script with special hook meaning. The following variables are recognized:
set modulefile_extra_vars {myvar 1 othervar {some text}}
In the above siteconfig example, modulefile_extra_vars sets the myvar and othervar variables in the modulefile evaluation context with respectively 1 and some text as value.
proc mycmd {} {
# Tcl code
}
proc anotherproc {args} {
# Tcl code
}
set modulefile_extra_cmds {mycmd mycmd othercmd anotherproc}
In the above siteconfig example, modulefile_extra_cmds sets the mycmd and othercmd commands in the modulefile evaluation context and bind them respectively to the mycmd and anotherproc procedures defined in siteconfig script.
set modulerc_extra_vars {myvar 1 othervar {some text}}
In the above siteconfig example, modulerc_extra_vars sets the myvar and othervar variables in the modulerc evaluation context with respectively 1 and some text as value.
proc mycmd {} {
# Tcl code
}
proc anotherproc {args} {
# Tcl code
}
set modulerc_extra_cmds {mycmd mycmd othercmd anotherproc}
In the above siteconfig example, modulerc_extra_cmds sets the mycmd and othercmd commands in the modulerc evaluation context and bind them respectively to the mycmd and anotherproc procedures defined in siteconfig script.
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.
The module command exits with 0 if its execution succeed. Otherwise 1 is returned.
This environment variable is set to 1 by the autoinit sub-command after checking it is not set. It ensures no nested initialization of Modules occur. At the end of the processing of the autoinit sub-command, __MODULES_AUTOINIT_INPROGRESS is unset.
Each alternative name stored in __MODULES_LMALTNAME is prefixed by the al| string if it corresponds to a module alias or prefixed by the as| string if it corresponds to an automatic version symbol. These prefixes help to distinguish the different kind of alternative name.
This environment variable is intended for module command internal use to get knowledge of the alternative names matching loaded 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-loaded or info-loaded actions are run over these names.
Starting version 4.7 of Modules, __MODULES_LMALTNAME is also used on list sub-command to report the symbolic versions associated with the loaded modules.
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.
This environment variable is intended for module command internal use to distinguish from all tags those that have been specifically set with --tag option.
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 reset sub-command. It can also be restored with restore sub-command when __init__ collection name is specified or when no collection name is specified and no default collection exists.
The content of the initial environment can be displayed with saveshow sub-command when __init__ collection name is specified or when no collection name is specified and no default collection exists.
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.
This environment variable is intended for module command internal use to get knowledge of the modulefile commands applied for each source-sh command when loading the modulefile. In order to reverse these modulefile commands when modulefile is unloaded to undo the environment changes.
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.
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.
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.
First element in list corresponds to the lastly set value of <VAR>. If a value were set to <VAR> prior the first evaluated pushenv command, this value is associated to an empty module name to record it as a pair element in __MODULES_PUSHENV_<VAR>.
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.
This environment variable is generated by module command and should not be modified externally.
This environment variable is generated by module command and should not be modified externally.
This environment variable value supersedes the default value set in the contact configuration option. It can be defined with the config sub-command.
Path elements registered in the MODULEPATH environment variable may contain reference to environment variables which are converted to their corresponding value by module command each time it looks at the MODULEPATH value. If an environment variable referred in a path element is not defined, its reference is converted to an empty string.
Several global run-command files may be defined in this environment variable by separating each of them by colon character.
This environment variable value supersedes the default value set in the rcfile configuration option. It can be defined with the config sub-command.
Accepted sub-commands that can be set in value list are:
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 the abort_on_error configuration option. It can be defined with the config sub-command.
This environment variable value supersedes the default value set in the advanced_version_spec configuration option. It can be defined with the config sub-command.
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:
When unloading a modulefile, following actions are triggered:
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.
This environment variable value supersedes the default value set on the auto_handling configuration option. It can be defined with the config sub-command. The --auto and --no-auto command line switches override this environment variable.
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 the avail_indepth configuration option. It can be defined with the config sub-command. The --indepth and --no-indepth command line switches override this environment variable.
Accepted elements that can be set in value list are:
The order of the elements in the list does not matter. Module names are the only content reported when LIST is set to an empty value.
In case the modulepath element is missing from value list, the available modules from global/user rc and all enabled modulepaths are reported as a single list.
When indesym element is set, dirwsym and sym elements are disabled.
This environment variable value supersedes the default value set in the avail_output configuration option. It can be defined with the config sub-command. The --output/-o command line switches override this environment variable.
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 the avail_terse_output configuration option. It can be defined with the config sub-command. The --output/-o command line switches override this environment variable.
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).
This environment variable is generated by module command and should not be modified externally.
This environment variable value supersedes the default value set in the collection_pin_version configuration option. It can be defined with the config sub-command.
This environment variable value supersedes the default value set in the collection_pin_tag configuration option. It can be defined with the config sub-command.
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 the collection_target configuration option. It can be defined with the config sub-command.
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 the color configuration option. It can be defined with the config sub-command. The --color command line switch overrides this environment variable.
NO_COLOR, CLICOLOR and CLICOLOR_FORCE environment variables are also honored to define color mode. The never mode is set if NO_COLOR is defined (regardless of its value) or if CLICOLOR equals to 0. If CLICOLOR is set to another value, it corresponds to the auto mode. The always mode is set if CLICOLOR_FORCE is set to a value different than 0. NO_COLOR variable prevails over CLICOLOR and CLICOLOR_FORCE. Color mode set with these three variables is superseded by mode set with MODULES_COLOR environment variable or with --color command line switch..
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 to 37 for foreground colors and 90 to 97 for 16-color mode foreground colors. See also https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Rendition)_parameters for a complete SGR code reference.
No graphical rendition will be applied to an output item that could normally be colored but which is not defined in the color set. Thus if MODULES_COLORS is defined empty, no output will be colored at all.
This environment variable value supersedes the default value set in the colors configuration option. It can be defined with the config sub-command.
This environment variable value supersedes the default value set in the editor configuration option. It can be defined with the config sub-command.
Text editor could also be defined through the VISUAL or EDITOR environment variables. These environment variables are overridden by MODULES_EDITOR.
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 (see MODULES_IMPLICIT_DEFAULT section)
This environment variable value supersedes the default value set in the extended_default configuration option. It can be defined with the config sub-command.
For instance if loading modulefile foo/1.0 defines being member of the bar family, the MODULES_FAMILY_BAR will be set to the foo value.
This environment variable is generated by module command and should not be modified externally.
This environment variable value supersedes the default value set in the icase configuration option. It can be defined with the config sub-command. The --icase/-i command line switches, which correspond to the always mode, override this environment variable.
This environment variable value supersedes the default value set in the ignore_cache configuration option. It can be defined with the config sub-command. The --ignore-cache command line switch overrides this environment variable.
This environment variable value supersedes the default value set in the ignore_user_rc configuration option. It can be defined with the config sub-command. The --ignore-user-rc command line switch overrides this environment variable.
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:
An error is returned in the above situations if either no explicit or implicit default version is defined.
This environment variable value supersedes the default value set in the implicit_default configuration option. It can be defined with the config sub-command. This environment variable is ignored if implicit_default has been declared locked in locked_configs configuration option.
This environment variable value supersedes the default value set in the implicit_requirement configuration option. It can be defined with the config sub-command. The --not-req option, applied to a module command in a modulefile, overrides this environment variable.
Accepted elements that can be set in value list are:
The order of the elements in the list does not matter. Module names are the only content reported when LIST is set to an empty value.
This environment variable value supersedes the default value set in the list_output configuration option. It can be defined with the config sub-command. The --output/-o command line switches override this environment variable.
See MODULES_LIST_OUTPUT to get the accepted elements that can be set in value list.
The order of the elements in the list does not matter. Module names are the only content reported when LIST is set to an empty value.
This environment variable value supersedes the default value set in the list_terse_output configuration option. It can be defined with the config sub-command. The --output/-o command line switches override this environment variable.
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:
When a module cache file is available for a given modulepath, eval mode is not applied as cache content is generated in always mode.
This environment variable value supersedes the default value set in the mcookie_check configuration option. It can be defined with the config sub-command.
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 the mcookie_version_check configuration option. It can be defined with the config sub-command.
This environment variable value supersedes the default value set in the ml configuration option. It can be defined with the config sub-command.
To enable or disable ml command, MODULES_ML should be set prior Modules initialization or the ml configuration option should be set in the initrc configuration file.
This environment variable value supersedes the default value set in the nearly_forbidden_days configuration option. It can be defined with the config sub-command.
This environment variable value supersedes the default value set in the pager configuration option. It can be defined with the config sub-command.
If MODULES_PAGER variable is set to an empty string or to the value cat, pager will not be launched.
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 the protected_envvars configuration option. It can be defined with the config sub-command.
The generated shell code for quarantine mechanism indirectly passes the environment variable defined in MODULES_RUN_QUARANTINE to the modulecmd.tcl script to protect its run-time environment from side-effect coming from the current definition of these variables.
To enable quarantine support, MODULES_QUARANTINE_SUPPORT should be set to 1 prior Modules initialization or the quarantine_support configuration should be set to 1 in the initrc configuration file.
Generated code for quarantine mechanism sets the __MODULES_QUARANTINE_SET environment variable when calling the modulecmd.tcl script to make it restore the environment variable put in quarantine.
This environment variable value supersedes the default value set in the quarantine_support configuration option. It can be defined with the config sub-command.
This environment variable value supersedes the default value set in the redirect_output configuration option. It can be defined with the config sub-command. The --redirect and --no-redirect command line switches override this environment variable.
This environment variable value supersedes the default value set in the reset_target_state configuration option. It can be defined with the config sub-command.
If the quarantine mechanism has been included in module shell function (see MODULES_QUARANTINE_SUPPORT), each variable found in MODULES_RUN_QUARANTINE will have its value emptied or set to the value of the corresponding MODULES_RUNENV_<VAR> variable when defining modulecmd.tcl run-time environment.
Original values of these environment variables set in quarantine are passed to modulecmd.tcl via __MODULES_QUAR_<VAR> variables.
This environment variable value supersedes the default value set in the run_quarantine configuration option. It can be defined with the config sub-command.
This environment variable value supersedes the default value set in the search_match configuration option. It can be defined with the config sub-command. The --starts-with and --contains command line switches override this environment variable.
This environment variable value supersedes the default value set in the set_shell_startup configuration option. It can be defined with the config sub-command.
To enable shell startup file, MODULES_SET_SHELL_STARTUP should be set to 1 prior Modules initialization or the set_shell_startup configuration option should be set to 1 in the initrc configuration file.
Accepted values are a list of shell among sh, bash, csh, tcsh and fish separated by colon character (:).
This environment variable value supersedes the default value set in the shells_with_ksh_fpath configuration option. It can be defined with the config sub-command.
To enable the setup of FPATH for some shells, MODULES_SHELLS_WITH_KSH_FPATH should be set to the list of these shells prior Modules initialization or the shells_with_ksh_fpath configuration option should be set to the list of these shells in the initrc configuration file.
This environment variable value supersedes the default value set in the silent_shell_debug configuration option. It can be defined with the config sub-command.
To generate the code to silence shell debugging property in the module shell function, MODULES_SILENT_SHELL_DEBUG should be set to 1 prior Modules initialization or the silent_shell_debug configuration option should be set to 1 in the initrc configuration file.
This environment variable value supersedes the default value set in the extra_siteconfig configuration option. It can be defined with the config sub-command. This environment variable is ignored if extra_siteconfig has been declared locked in locked_configs configuration option.
This environment variable value supersedes the default value set in the source_cache configuration option. It can be defined with the config sub-command.
This environment variable value supersedes the default value set in the sticky_purge configuration option. It can be defined with the config sub-command.
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 the tag_abbrev configuration option. It can be defined with the config sub-command.
When a select graphic rendition is defined for a tag name or a tag abbreviation string, it is applied over the module name associated with the tag and tag name or abbreviation is not displayed. When listed in MODULES_TAG_COLOR_NAME environment variable, a tag name or abbreviation is displayed and select graphic rendition is applied over it.
This environment variable value supersedes the default value set in the tag_color_name configuration option. It can be defined with the config sub-command.
This environment variable value supersedes the default value set in the tcl_linter configuration option. It can be defined with the config sub-command.
This environment variable value supersedes the default value set in the term_background configuration option. It can be defined with the config sub-command.
This environment variable value supersedes the default value set in the term_width configuration option. It can be defined with the config sub-command. The --width/-w command line switches override this environment variable.
This environment variable value supersedes the default value set in the unique_name_loaded configuration option. It can be defined with the config sub-command.
This environment variable value supersedes the default value set in the unload_match_order configuration option. It can be defined with the config sub-command.
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 the variant_shortcut configuration option. It can be defined with the config sub-command.
This environment variable value supersedes the default value set in the verbosity configuration option. It can be defined with the config sub-command. The --silent, --verbose, --debug and --trace command line switches override this environment variable.
This environment variable value supersedes the default value set in the wa_277 configuration option. It can be defined with the config sub-command.
To enable this workaround, MODULES_WA_277 should be set to 1 prior Modules initialization or the wa_277 configuration option should be set to 1 in the initrc configuration file.
This environment variable value supersedes the default value set in the home configuration option. It can be defined with the config sub-command.
/usr/share/modules
/etc/environment-modules/initrc
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 with module config. As any modulefile initrc must begin with the Modules magic cookie (i.e., #%Module file signature).
initrc is optional. When this configuration file is present it is evaluated after the modulespath configuration file. See the Package Initialization section for details.
/etc/environment-modules/modulespath
modulespath is optional. When this configuration file is present it is evaluated before the initrc configuration file. See the Package Initialization section for details.
/etc/environment-modules/siteconfig.tcl
/etc/environment-modules/rc
$HOME/.modulerc
$HOME/.module
/usr/share/modules/modulefiles
<modulepath>/.modulerc
<modulepath>/.modulecache
/usr/lib/x86_64-linux-gnu/modulecmd.tcl
/usr/share/modules/init/<shell>
ml, modulefile
1996-1999 John L. Furlani & Peter W. Osel, 1998-2017 R.K.Owen, 2002-2004 Mark Lakata, 2004-2017 Kent Mein, 2016-2024 Xavier Delaruelle
| 2024-02-20 | 5.4.0 |