gBAR

Purpose

Modules, as the name implies, is a modular approach to system environment variable manipulation, in particular PATH and MANPATH. Should you not be familiar with these variables (and environment variables in general), the purpose of these are, to adjust how different parts of the system and different programs work during runtime.

The PATH variable is interpreted by your shell (commonly this would be bash), and defines all the directories on the system which you should be able to run programs from, where ever your current directory might be on the command line, without specifying absolute path to the program (an example would be the possibility of typing "firefox" to start a program from the command line, as opposed to its full path, which is "/apps/dcc/bin/firefox"). The MANPATH works in a similar way, but this one adjusts the availability of man pages for your daily day programs and their friends.

Modules makes it possible to control variables like these with a simple tool "module" from the command line.

This especially has its uses on large multi user systems, where different users need different tools. Normally all of these users need a wide range of programs available to them, in particular from the command line. The consequence of this is, that one big pool of programs become available to all users. One big pool of programs has several downsides. First, it is very inefficient. bash has to scan all the directories specified in the PATH variable in order to provide you with the option of running the programs located in them, and it should be self explanatory, that the more directories specified in the variable, the more work bash has to perform. Another problem is that it is error prone, especially in regards to availability of multiple versions of the same program. When are you running which version? Can you be sure you are running the right one? Do they conflict with each other? This is very crucial in regards to compilers, just to provide an example.

Problems like these are eliminated by modules, because it works on a reduced PATH, and then adds or removes directories depending on your input.

Use

As previously mentioned, modules are run from the command line with the command:

 $ module

several options are available to the user, specified as arguments to the module command, a few of most important are:

  • help - lists all possible arguments to the module command
  • avail - lists all loadable modules
  • display/show - lists what the module does, e.g. what paths are appended to your PATH
  • list - lists all loaded modules
  • load - loads a module
  • unload - unloads a module
  • swap - swaps one module to another
  • whatis - prints a short description of a module and its purpose

An example of module loading:

 $ module load gcc
 Loaded dependency [gcc/4.0.2]: xpg
 Loaded module: gcc/4.0.2

Automatic module loading

It is possible to load one or several modules automatically every time you start a new shell. Simply edit the .gbarrc file in your home dir (or create it if it does not exist):

$ nano -w ~/.gbarrc

Then type in the modules you want to load every time you start a new shell, as a comma separated list as follows (example):

MODULES=gcc,tmux/2.0

Finally type Ctrl+o, press y (or <enter>) and then enter to save, and finally Ctrl+x to exit.

NOTICE

24
01 2017
Please note that the IT support office has been moved to the DTU library. Latex support remains in 308.
02
12 2015
Want to take advantage of the new GitLab service, or perhaps move your existing repos project over? Check out http://www.gbar.dtu.dk/faq/94-gitlab
07
04 2015
ShareLaTex We now offer ShareLatex, an online mulituser system for making LaTex documents. Check out http://gbar.dtu.dk/faq/91-sharelatex and https://www.sharelatex.com/