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.

  • Executables
  • Libraries
  • Modules
  • Scripts
  • Defaults

    Executables

    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/bin
    
    Either 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 Computing
    
    or 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 ~]$ setenv PATH /usr/local/apps/R/gcc_4.8.5/R-3.5.1/bin:$PATH
    [unityID@login ~]$ R
    

    back to top

    Libraries

    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.

    Example:
    [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 directory
    
    In 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)
    

    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.14
    
    back to top

    Modules

    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.

    To find available modules:
    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
    

    User defined custom 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

    back to top

    Scripts

    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.0
    
    Then type source cuda.csh

    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

    Default environment

    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
  • Copyright © 2022 · Office of Information Technology · NC State University · Raleigh, NC 27695 · Accessibility · Privacy · University Policies