module

Display available modules

$ module avail

$ module avail [module_name]

$ module load [module_name]

$ module list

$ module unload [module_name]

$ module purge

$ module use [path/to/module_file1 path/to/module_file2 ...]

module subcommand [ modulefile ... | option ]

avail
    Lists all available modulefiles in the configured search paths.

list
    Displays all modulefiles currently loaded into the user's environment.

load modulefile...
    Loads one or more specified modulefiles, applying their environment modifications.

unload modulefile...
    Unloads one or more specified modulefiles, reverting their environment modifications.

swap old_module new_module
    Atomically unloads the old_module and loads the new_module.

show modulefile
    Displays the contents and intended environment changes of a modulefile without actually loading it.

purge
    Unloads all currently loaded modulefiles from the environment.

help [ modulefile ]
    Provides help information about the module command itself or about a specific modulefile.

use directory
    Adds directory to the MODULEPATH, allowing modulefiles in that directory to be found.

unuse directory
    Removes directory from the MODULEPATH.

The module command is part of the Environment Modules package, a tool designed to simplify the management of a user's shell environment. It allows for the dynamic modification of environment variables such as PATH, LD_LIBRARY_PATH, MANPATH, etc., without the need for manual configuration. This is particularly useful in environments where multiple versions of software or libraries exist (e.g., HPC clusters, research labs) and users need to switch between them easily. Instead of modifying shell startup scripts directly, users load or unload pre-defined "modulefiles," which are scripts that define how to set up the environment for a particular software package or version. This approach promotes reproducibility, reduces configuration errors, and allows for clean switching between different software stacks, making complex software landscapes manageable and accessible.

The module command is typically implemented as a shell function or script sourced into the user's environment, rather than a standalone executable. This means its availability and exact behavior depend on the 'Environment Modules' package being installed and properly initialized in the user's shell startup files. It is most commonly found and utilized in shared computing environments like High-Performance Computing (HPC) clusters or academic labs.

Modulefiles are the core of the module system. They are typically plain-text scripts (often written in Tcl, but also Lua or other languages) that define how to modify the user's environment (e.g., adding paths to PATH, setting specific environment variables) for a particular software package or version. Administrators create and maintain these files to provide users with curated software stacks.

The module command searches for modulefiles in directories specified by the MODULEPATH environment variable. This variable contains a colon-separated list of directories. Users can extend this path using the module use subcommand, allowing them to access modulefiles in custom or project-specific locations.

The Environment Modules package, which provides the module command, was developed by John L. Furlong at the Ohio Supercomputer Center (OSC) in the early 1990s. It was created to address the challenges of managing multiple software versions and dependencies in shared computing environments. Its effectiveness and flexibility have led to its widespread adoption, making it a de facto standard for environment management in many scientific and research computing facilities.

tclsh(1), bash(1), csh(1), zsh(1), export(1), source(1)