MODULE(1)

📦 version 4.8.0, in opensuse-leap 16.0

🦋 MODULE(1) — command interface to the Modules package 🦋

🌸 NAME 🌸

module — the command interface to the Modules package. That’s the whole mood, bestie. 💅

✨ SYNOPSIS ✨

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

💖 DESCRIPTION 💖

Okay so module is your user interface to the Modules package, and the Modules package is the thing that provides for the dynamic modification of the user’s environment via modulefiles. It’s giving “shell glow-up on demand.” ✨

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 tell module to alter or set shell environment variables such as PATH, MANPATH, etc. modulefiles may be shared by many users on a system, and users may have their own collection to supplement or replace the shared modulefiles. 🫶

The modulefiles are added to and removed from the current environment by the user. The environment changes contained in a modulefile can also be summarized through the module command. If no arguments are given, a summary of the module usage and sub-commands is shown. No cap. 💀

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

🧚 Package Initialization 🧚

The Modules package and the module command are initialized when a shell-specific initialization script is sourced into the shell. The script creates the module command — either as an alias or shell function — creates Modules environment variables, and if enabled to do so, a snapshot of the environment is saved as either (if BEGINENV=1) $HOME/.modulesbeginenv or (if BEGINENV=99) whatever $MODULESBEGINENV points to. Slay. 🎀

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

The initialization scripts are kept in $MODULESHOME/init/<shell> where <shell> is the name of the sourcing shell. The sh, csh, tcsh, bash, ksh, and zsh shells are supported by modulecmd. In addition, python, perl, and cmake “shells” are supported, which writes the environment changes to stdout as python, perl, or cmake code. Iconic behavior. 👑

The perl module command is set up with:

use lib $ENV{'MODULESHOME'}."/init";
use perl;

And the python module command is defined with:

import os, sys;
sys.path.insert(0, '@INITPATH@')

from python import module;

🔥 Modulecmd startup 🔥

Upon invocation, modulecmd sources rc files which contain global, user and modulefile specific setups. These files are interpreted as modulefiles. See modulefile(4) for detailed information. iykyk, bestie. ☕

Upon invocation of modulecmd, module RC files are sourced in the following order:

  1. Global RC file as specified by ${MODULERCFILE} or ${MODULESHOME}/etc/rc
  2. User specific module RC file ${HOME}/.modulerc
  3. All .modulerc and .version files found during modulefile seeking.

🎀 Command line switches 🎀

The module command accepts command line switches as its first parameter. These may be used to control the output format of all information displayed and the module behavior in case of locating and interpreting module files. Vibe check: these switches can really change the output. ✨

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

  • --help, -H — gives some helpful usage information, and terminates the command.
  • --version, -V — lists the current version of the module command, and some configured option values. The command then terminates without further processing.
  • --force, -f — force active dependency resolution. This will result in modules found on a prereq command inside a module file being loaded automatically. Unloading module files using this switch will result in all required modules which have been loaded automatically using the -f switch being unloaded. This switch is experimental at the moment.
⚠️ ngl, --force, -f is experimental rn. Treat it like a beta feature, bestie.
  • --terse, -t — display avail and list output in short format. Lowkey the “keep it cute” option.
  • --long, -l — display avail and list output in long format. Highkey the “give me the lore” option.
  • --human, -h — display short output of the avail and list commands in human readable format.
  • --verbose, -v — enable verbose messages during module command execution.
  • --silent, -s — disable verbose messages. Redirect stderr to /dev/null if stderr is found not to be a tty. This is a useful option for module commands being written into .cshrc, .login, or .profile files, because some remote shells (as rsh(1)) and remote execution commands (like rdist) get confused if there is output on stderr. The way that -s protects your stderr from chaos is iconic. 😭
  • --create, -c — create caches for module avail and module apropos. You must be granted write access to the ${MODULEHOME}/modulefiles/ directory if you try to invoke module with the -c option.
👑 Heads up: -c means you need write access to ${MODULEHOME}/modulefiles/. No write access? No cache magic.
  • --icase, -i — case insensitive module parameter evaluation. Currently only implemented for the module apropos command.
  • --userlvl <lvl>, -u <lvl> — set the user level to the specified value. The argument of this option may be one of:
    • novice, nov — Novice
    • expert, exp — Experienced module user
    • advanced, adv — Advanced module user

🌈 Module Sub-Commands 🌈

Main character energy only. Here’s the sub-command lineup:

  • help [modulefile...] — print the usage of each sub-command. If an argument is given, print the Module-specific help information for the modulefile(s).
  • add modulefile..., load modulefile... — load modulefile(s) into the shell environment. 🫶
  • rm modulefile..., unload modulefile... — remove modulefile(s) from the shell environment.
  • swap [modulefile1] modulefile2, switch [modulefile1] modulefile2 — switch loaded modulefile1 with modulefile2. If modulefile1 is not specified, then it is assumed to be the currently loaded module with the same root name as modulefile2.
  • show modulefile..., display modulefile... — display information about one or more modulefiles. The display sub-command will list the full path of the modulefile(s) and all (or most) of the environment changes the modulefile(s) will make if loaded. (It will not display any environment changes found within conditional statements.)
  • list — list loaded modules.
  • avail [path...] — list all available modulefiles in the current MODULEPATH, where the sorting order is given by the LC_COLLATE locale environment variable.

All directories in the MODULEPATH are recursively searched for files containing the modulefile magic cookie. 🍓

If an argument is given, then each directory in the MODULEPATH is searched for modulefiles whose pathname match the argument.

Multiple versions of an application can be supported by creating a subdirectory for the application containing modulefiles for each version. Obsessed with this versioning moment.

  • use [-a|--append] directory... — prepend one or more directories to the MODULEPATH environment variable. The --append flag will append the directory to MODULEPATH.
  • unuse directory... — remove one or more directories from the MODULEPATH environment variable.
  • update — attempt to reload all loaded modulefiles. The environment will be reconfigured to match the environment saved in ${HOME}/.modulesbeginenv (if BEGINENV=1) or the file pointed at by $MODULESBEGINEV (if BEGINENV=99) and the modulefiles will be reloaded. This is only valid if modules was configured with --enable-beginenv (which defines BEGINENV), otherwise this will cause a warning. update will only change the environment variables that the modulefiles set.
⚠️ update only works if modules was configured with --enable-beginenv (which defines BEGINENV). Otherwise: warning town. Periodt.
  • clear — force the Modules package to believe that no modules are currently loaded. Not me being dramatic about clear — it just forces the Modules package to believe nothing is loaded.
  • purge — unload all loaded modulefiles. Bye bestie. 👋
  • refresh — force a refresh of all non-persistent components of currently loaded modules. This should be used on derived shells where aliases need to be reinitialized but the environment variables have already been set by the currently loaded modules.
  • whatis [modulefile...] — display the information set up by the module-whatis commands inside the specified modulefile(s). If no modulefile is specified, all 'whatis' lines will be shown.
  • apropos string, keyword string — seeks through the 'whatis' informations of all modulefiles for the specified string. All module-whatis informations matching the string will be displayed.
  • initadd modulefile... — add modulefile(s) to the shell’s initialization file in the user’s home directory. The startup files checked (in order) are:
    • csh — .modules, .cshrc(.ext), .csh_variables, and .login(.ext)
    • tcsh — .modules, .tcshrc, .cshrc(.ext), .csh_variables, and .login(.ext)
    • sh and ksh — .modules, .profile(.ext), and .kshenv(.ext)
    • bash — .modules, .bash_profile, .bash_login, .profile(.ext), and .bashrc(.ext)
    • zsh — .modules, .zcshrc(.ext), .zshenv(.ext), and .zlogin(.ext)
  • initadd (cont.) — if a module load line is found in any of these files, the modulefile(s) is(are) appended to any existing list of modulefiles. That module load line must live in at least one of the files listed above for any of the init sub-commands to work properly. And if the module load line shows up in multiple shell initialization files? All of the lines get changed. 💅
  • initprepend modulefile [modulefile...] — same as initadd but it prepends the given modules to the beginning of the list.
  • initrm modulefile... — removes modulefile(s) from the shell's initialization files.
  • initswitch modulefile1 modulefile2 — switches modulefile1 with modulefile2 in the shell's initialization files. 🔁
  • initlist — lists all of the modulefiles loaded from the shell's initialization file.
  • initclear — clears all of the modulefiles from the shell's initialization files. poof, gone 🫧

🦋 Modulefiles 🦋

okay so modulefiles are written in the Tool Command Language (Tcl) and they get interpreted by modulecmd. They can use conditional statements, which is honestly so cool — meaning the effect a modulefile has on the environment may change depending on the current state of the environment. it's giving sentient 😭

⚠️ heads up bestie: environment variables are unset when unloading a modulefile. So yes, you can load a modulefile and then unload it, and the environment variables will not return to their prior state. no cap, that's just how it is.

🌈 ENVIRONMENT 🌈

  • MODULESHOME — the location of the master Modules package file directory. It contains the module command initialization scripts, the executable program modulecmd, and a directory holding a collection of master modulefiles. 🏠
  • MODULEPATH — the path that the module command searches when it's looking for modulefiles. Typically it's set to a default value by the bootstrap procedure. MODULEPATH can be set using module use, or by the module initialization script, to search group or personal modulefile directories before or after the master modulefile directory. 🔍
  • LOADEDMODULES — a colon separated list of all loaded modulefiles.
  • _LMFILES_ — a colon separated list of the full pathname for all loaded modulefiles.
  • MODULESBEGINENV — if modules has been configured (BEGINENV=99) to test for this environment variable, then if it exists, it is the name of the file to store the initial shell environment. This environment variable will have embedded environment variables unrolled to one level. The contents of this variable is only used the first time modules is invoked. ⏰
  • _MODULESBEGINENV_ — the filename of the file containing the initialization environment snapshot.

🎀 FILES 🎀

  • /usr/Modules — the MODULESHOME directory.
  • ${MODULESHOME}/etc/rc — the system-wide modules rc file. The location of this file can be changed using the MODULERCFILE environment variable as described above. ✨
  • ${HOME}/.modulerc — the user specific modules rc file.
  • ${MODULESHOME}/modulefiles — the directory for system-wide modulefiles. The location of the directory can be changed using the MODULEPATH environment variable as described above.
  • ${MODULESHOME}/bin/modulecmd — the modulefile interpreter that gets executed upon each invocation of module. ⚙️
  • ${MODULESHOME}/init/<shell> — the Modules package initialization file sourced into the user's environment.
  • ${MODULEPATH}/.moduleavailcache — file containing the cached list of all modulefiles for each directory in the MODULEPATH (only when the avail cache is enabled via the configure option --enable-cache, which sets CACHE_AVAIL).
  • ${MODULEPATH}/.moduleavailcachedir — file containing the names and modification times for all sub-directories with an avail cache (see above).
  • ${HOME}/.modulesbeginenv — a snapshot of the user's environment taken at Module initialization. This information is used by the module update sub-command (if BEGINENV=1), else…
  • $MODULESBEGINENV — if this defines a valid filename, it serves the same purpose as above (if BEGINENV=99). 🫶

⭐ VERSION ⭐

3.2.13

👑 SEE ALSO 👑

modulefile(4) — go read it, iykyk 💖

and that's the whole thing, bestie! this lil masterpiece is Modules version 3.2.13, dated 2020-04-07 — a vintage icon honestly, we stan a classic 🎀💜✨

📦 where this page comes from