The intent of this document is to introduce the Modules package as it is installed on the CS and IT Labs environments. All accounts are now using Modules. We no longer support methods of setting up your environment (path and other environment variables) other than Modules.

Please read the Module manpage. It explains the available options. For more detailed information, see John L. Furlani's article titled "Modules: Providing a Flexible User Environment" or check out the Modules Project home page.

The Modules package provides a single command line interface for manipulating your UNIX environment. The Modules interface enables users to easily add, change, and remove application specific paths, aliases, and environmental variables from your environment.

Instead of asking where something is located, you just inform Modules which package you want, using the 'module load' command and it adjusts your environment 'on the fly' so that you are able to use the package or application.

For example, the following is a typical module section taken from a user's shell start up file, in this case the shell is tcsh:

# initialize the modules system for tcsh use
source /soft/rko-modules/tcl/init/tcsh
# load my modules
module load system local gnu x11 math/matlab mcad/proe

The above code would have prepared the users environment so that he or she could access:

1. The basic system commands (system)
2. Locally installed public domain software (local, /usr/local)
3. GNU software like gcc and emacs (gnu)
4. X Windows (x11)
5. Matlab (math/matlab)
6. ProEngineer (mcad/proe)

The order of the modules listed on your module load line is significant because it is in this order in which your PATH, MANPATH, and other variables are modified. This is because the convention that I chose to use was to always append items to variables which contained multiple elements.

For example, both the 'system' module and the 'gnu' module add an entry to your PATH variable which contains a binary called tar. If you prefer to use the 'system' tar over the 'gnu' tar, then you need to make sure that 'system' comes before 'gnu' on your module load line.

To find out what modules are available use the following command:

% module avail

Why would anyone need a tool to set their paths? Well, in large heterogeneous UNIX environments like our own, the paths to commands vary from system to system. Users seeking a consistent environment usually end up writing fairly complex shell startup files. These startup files tend to be filled to the brim with nested if statements, multiple hostname and uname commands, and a myriad of other bits of logic. Everyone has the same goal but everyone does it differently and spends (or wastes?) a lot of time doing it. Sure it's educational the first time, but it usually ends up being frustrating after the initial novelty wears off.

Modules pushes the responsibility of environment configuration onto the system administrator, not the user(s). The Modules user only needs to know the symbolic name for a given package and he or she will always be assured the the correct paths are being set, no matter which system the user is on.

You are probably thinking that we could just do this with a global set of shell scripts, one for each shell, and you are right. Modules improves on that paradigm in several ways:

1. SHELL independent configuration files

   Modules is configured by the system administrator by creating one file for every package that needs the environment to be modified. With the shell script paradigm, a script for each shell would need to be created.

   If a package is moved or goes away, the system administrator needs to only edit the one file.

2. User level customization

   Part of the problem with the global shell script paradigm is that it's usually an all or nothing situation for the user. With Modules, the User can decide which packages he or she wants to be configured for.

   Also, an additional benefit to the user is that each module is self documenting. A user can query the module using either the 'show' or 'help' directive and learn what effect the module will have on his or her environment in addition to any special instructions related to the package. For example:

   % module show gnu
   -------------------------------------------------------------------
   /opt/modules/modulefiles/gnu:
   
   Append  /opt/gnu/bin to PATH
   Append  /opt/gnu/man to MANPATH
   -------------------------------------------------------------------
   % module help frame
   ----------- Module Specific Help for 'frame' ----------------------
   
      Framemaker
   
      Framemaker is a word processing package.  To use it,
      load this module and type 'maker'.
   
      Online documentation is available from within the application.
   

3. Interactive environment modification

   Modules users can load or unload any module interactively. This allows users who seldom use a given package to not be encumbered with the PATHs and variables associated with packages that are infrequently used.

   For example, I only use Frame Maker a couple times a month, so instead of configuring my startup file for use with frame, I just load the module when I need it like so:

   % module load frame ; maker
   

   Modules adjusts my environment on the fly and I'm running frame.

4. User modules

   Anyone can create their own modules in addition to the system supplied ones. Users intent on not being dependent on their system administrators can roll their own if they'd like. If you plan on making your own module files, be sure to read the section of the module manpage about the 'use' option.

Once again, please let us know if you have any questions about the use of modules.