Shells and Scripting

This page describes the UNIX user environment on NERSC computers. Included are pointers to web resources related to the standard shells. Additional shells, not always supported by the vendors, have been installed by NERSC and include the tcsh and bash shells.

A number of scripting languages are also available, including TCL, Python, and Perl.

• NERSC-Defined Environment
• User Modifications to Environment
• Troubleshooting and Cautions

Related Information

• TCL/TK
• Perl
• Python

NERSC Defined Environment

A default user home directory is created on each machine. The home directory should always be referred to by the shell environment variable:

  $HOME  

Login Environments

You can change shells through the NIM web interface; see Change Default Login Shell.

With the POSIX shells (sh and ksh), when a login shell is opened commands are read first from /etc/profile and then from .profile in the user home directory. Next commands are read from the file named by the ENV parameter (usually file .kshenv in the user home directory).

With the C shell (csh), when a login shell is opened commands are read first from /etc/csh.cshrc and then from .cshrc and .login in the user home directory.

The /etc/profile and /etc/csh.cshrc files define the default system environment and initialize modules. Please see the introductory page on modules.

Some important initializations must be done in the user's startup or "dot" files. Template dot files, located in the directory /usr/common/usg/etc/skel are placed in a new user's home directory. It is very important that users avoid redefining paths and environment variables set in these dot files.

When login shells are started they read information from the files shown above following the route shown by the black arrows. NERSC strongly recommends that users have their initialization files execute via the path of the red arrows shown above. See the next section: User Modifications to the Environment.

User Modifications to the Environment

With the use of modules users do not in general need to modify their UNIX initialization files in order to use different software packages. See the Modules web page for more information.

If a user wishes to add to the initialization files that were supplied when their account was created, it is recommended that they source $HOME/.cshrc.ext from their default $HOME/.cshrc file (similarly for .login and .profile) and then make all modifications in the $HOME/.cshrc.ext file only.

For example, these line should be at the end of a $HOME/.cshrc file:

	if ( -f $HOME/.cshrc.ext ) then 
       		source $HOME/.cshrc.ext
	endif

POSIX shell users can source the .profile.ext with these lines in the $HOME/.profile file.

	if [ -f $HOME/.profile.ext ]
	then
        	. $HOME/.profile.ext
	fi

In order to avoid confusion between system and user modifications to the environment variables, users should alway make changes by way of augmentation rather than redefinition of the PATH, etc.

For example, in the $HOME/.cshrc.ext file, add your directories to the path as follows:

   set path = ($path /project1/bin /project2/bin)

For users of a POSIX shell, the way to modify a path in the ~/.profile.ext file is:

   PATH=$PATH:/project1/bin:/project2/bin
  

Troubleshooting and Cautions

1. Please do not copy startup files from other machines

Users should never copy startup files from other machines. This will cause much confusion. Users may copy their favorite customizations (alias, etc.) to an extension file and then check for any conflicts with the default environment.

Copies of template startup files are available in the directory /usr/common/usg/etc/skel. These are the startup files that are placed in a new user's home directory.

2. Caution when customizing the environment

Users are encouraged to become familiar with the default, system-defined environment before making customizations. Customizations should be in the extensions to the startup files (such as ./cshrc.ext), not in the startup files themselves.

Users should be sure that their customizations do not conflict with system defined environment variables and aliases. If you find that something is "missing" in your environment, first remove your customizations and see if they are causing a conflict with the system-defined environment.

3. Caution when modifying path

Users should never redefine their path; rather additional directories should be prepended or appended to the existing path. Most path modifications should be done by modules rather than directly by the user.

Commands such as:

   set path = (dir1 dir2 ...)
   setenv LD_LIBRARY_PATH dir1:dir2 ...

are an invitation to disaster.

4. Troubleshooting: I made an error in my initialization files and now can't log in

If find you are unable to log in to your account, contact NERSC Consulting.