Environment variables are used to define various system settings, including the locations of executables and libraries. At login, a set of default environment variables are defined. A user may add to or modify these settings using shell commands. The default shell on Hazel is bash, and the following examples are valid in the default shell.
An executable is a program, and a program is usually started by typing the executable name. For the computer to find the executable, either the whole path to the executable must be given or the directory location of the executable has to be added to the list of places that the computer looks for executables. This list of directories to search for executables is called the path.
Example:
[unityID@login ~]$ R R: Command not found.The computer does not know where the program R is located. The computer looks for executables that are located in the default path, defined as
PATH:
[unityID@login ~]$ echo $PATH /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/usr/lpp/mmfs/binEither the whole path to the executable is given, i.e.,
[unityID@login ~]$ /usr/local/apps/R/gcc_4.8.5/R-3.5.1/bin/R R version 3.5.1 (2018-07-02) -- "Feather Spray" Copyright (C) 2018 The R Foundation for Statistical Computingor the
PATH must be modified to include the location of the executable, which in this case is preferably done by calling module load R, but can also be done with:
[unityID@login ~]$ export PATH=/usr/local/apps/R/gcc_4.8.5/R-3.5.1/bin:$PATH [unityID@login ~]$ Rback to top
Libraries may be called by an executable or may be necessary during compilation. The library locations must be specified. The list of directories in which to search for libraries is defined as LD_LIBRARY_PATH.
[unityID@login CUDA_Hello_World]$ ./a.out ./a.out: error while loading shared libraries: libcudart.so.9.0: cannot open shared object file: No such file or directoryIn the above example, the program a.out cannot find the CUDA libraries. They need to be added to the library path, which in this case is preferably done by calling
module load cuda, but may also be done with:
export LD_LIBRARY_PATH=/usr/local/apps/cuda/cuda-9.0/lib64:$LD_LIBRARY_PATH
To examine which libraries are included in either executables or other libraries, use ldd [library or executable] or strings [binary file].
For example, the program pmemd from Amber requires the Intel libraries. Here is one of the lines of output from ldd before and after the Intel module is used:
[unityid@login ~]$ ldd /usr/local/apps/amber18/bin/pmemd libsvml.so => not found [unityid@login ~]$ module load PrgEnv-intel [unityid@login ~]$ ldd /usr/local/apps/amber18/bin/pmemd libsvml.so => /opt/intel/compilers_and_libraries_2017.1.132/linux/compiler/lib/intel64/libsvml.so (0x00007f3a0aef1000)
Use strings to search for specific libraries within a bigger library. For example, to see if a certain version of GLIBCXX is included in the system installed standard C++ package, do:
[unityid@login ~]$ strings /lib64/libstdc++.so.6 | grep GLIBCXX_3.4.14 GLIBCXX_3.4.14back to top
Modules are an easy way of setting environment variables; they define the correct PATH, LD_LIBRARY_PATH, and any other variables necessary for the relevent program. Using modules is the preferred way of setting the environment.
module avail # show available modules module load [module] # load a module module list # list all loaded modules module unload [module] # unload a module module purge # unload all modules
Typing module avail will show the staff installed modules that are available system wide. Users and groups are encouraged to create their own modules. See:
Creating custom modules
Setting the environment using a script is done by saving the commands in a text file and sourcing the file. For example, create a file called cuda.sh containing the text:
#cuda environment export PATH=/usr/local/apps/cuda/cuda-9.0/bin:$PATH export LD_LIBRARY_PATH=/usr/local/apps/cuda/cuda-9.0/lib64:$LD_LIBRARY_PATH export CUDA_HOME=/usr/local/apps/cuda/cuda-9.0Then type
. cuda.sh
In lieu of setting the environment with a script, users and groups are encouraged to create custom modules for their user maintained software.
back to topThe default environment upon logging in may be found by using printenv. User loaded modules may be unloaded (module unload [module] or module purge), but if other non-default variables are set, the user should log out and log back in as the simplest way to make sure the environment goes back to the default environment.
It is strongly recommended that the default environment not be changed by adding commands to login files such as .login or .cshrc. Instead, set the environment by creating custom scripts and using the source command. Source the files only when necessary, such as before compilation or for running a job.
back to top