Access Unix Software
We use a module system to manage software in UNIX.
Use the table below to find the action and corresponding command you need, then from a command prompt on a UNIX or Linux lab machine, type and execute the command.
|Show available modules||
|Remove a module once||
|Load the module every time you log on||
|Remove and prevent a module from loading on log on||
If a module has multiple versions available, you can leave the version off and you will use the default, which may change to a newer version over time. For example, to load the default version of Firefox when you log in, type: % module initadd mozilla/firefox.
The intent of this document is to introduce the Modules package as it is installed on the CSE 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
# load my modules
module load system local gnu x11 math/matlab mcad/proe
The above code would prepare the user's environment so they could access:
- The basic system commands (system)
- Locally installed public domain software (local, /usr/local)
- GNU software like GCC and emacs (gnu)
- X Windows (x11)
- Matlab (math/matlab)
- 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 view available modules, run:
% module avail
The benefits of a tool to set paths become apparent in large heterogeneous UNIX environments like our own. The paths to commands vary from system to system, so users seeking a consistent environment often write fairly complex shell startup files. These startup files tend to consist of nested "if" statements, multiple hostname and uname commands, and a myriad of other bits of logic. Every user has the same goal, but each achieves it differently and spends (or wastes?) a lot of time doing so.
Modules transfers the responsibility of environment configuration to the system administrator, not the user(s). The user only needs to know the symbolic name for a given package; they will always be assured the the correct paths are being set, no matter which system the user is on.
This could be done with a global set of shell scripts, one for each shell, but modules improves on that paradigm in several ways:
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 removed, the system administrator needs only edit one file to reflect the change.
User level customization
Part of the problem with the global shell script paradigm is that it creates an "all or nothing" situation for the user. With Modules, the user can decide for which packages they want their environment configured.
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 their environment in addition to any special instructions related to the package. For example:
% module show gnu
Append /opt/gnu/bin to PATH
Append /opt/gnu/man to MANPATH
% module help frame
----------- Module Specific Help for 'frame' ----------------------
Framemaker is a word processing package. To use it,
load this module and type 'maker'.
Online documentation is available from within the application.
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 by its associated PATHs and variables.
For example: say a user uses Frame Maker a couple times a month. Instead of configuring their startup file for use with frame, they just load the module whenever they need it:
% module load frame ; maker
Modules adjusts the user's environment so they can use frame when they need it.
Anyone can create their own modules in addition to the system supplied ones. Users who don't want to be dependent on system administrators can roll their own. If you plan on making your own module files, be sure to read the section of the module manpage about the 'use' option.
Please let us know if you have any questions about the use of modules.
UNIX Text Editors
Several editors are available, including vi, vim, emacs, XEmacs, and pico. In order to access the software, you will need to type a specific UNIX command. For example, for XEmacs you will need to type: module initadd soft/xemacs and log out and back in to set it up on your account.
Contact: 1-201 Keller Hall, 200 Union St SE, Minneapolis, MN 55455 Phone: (612) 625-0876 Email: firstname.lastname@example.org