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 Henry2 is tcsh, 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.
[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
[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
PATHmust 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 ~]$ setenv 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
[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:
setenv 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)
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
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
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.csh containing the text:
#cuda environment setenv PATH /usr/local/apps/cuda/cuda-9.0/bin:$PATH setenv LD_LIBRARY_PATH /usr/local/apps/cuda/cuda-9.0/lib64:$LD_LIBRARY_PATH setenv CUDA_HOME /usr/local/apps/cuda/cuda-9.0Then type
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 top
The 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