Linux PATHs

Introduction

Environmental variables are a class of variables (i.e., items whose values can be changed) that tell the shell (like Bash or Tcsh) how to behave as the user works at the command line (i.e., in a text-only mode) or with shell scripts (i.e., short programs written in a shell programming language). A shell is a program that provides the traditional, text-only user interface for Unix-like operating systems; its primary function is to read commands that are typed in at the command line and then execute (i.e., run) them.

The default PATH

PATH is an environmental variable in Linux and other Unix-like operating systems that tells the shell which directories to search for executable files (i.e., ready-to-run programs) in response to commands issued by a user.

Let's try to run SAMtools on Lonestar. Go to your Terminal shell window and type samtools. What happens?

login1$ samtools
-bash: samtools: command not found

It turns out we have to tell PATH where to find the samtools program (as well as other programs we want to use for our analyses). How do we do that? First, some background: Your PATH consists of a series of colon-separated absolute paths in the file system. Whenever you type in a command at the command line that is not built into the shell or that does not include its absolute path, and then presses the 'Return' key, the shell searches through those directories, which constitute the user's search path, until it finds an executable file with that name.

*Let's look at the default PATH for your shell.* Type in {{echo $PATH}} and hit 'Return'.
{expand:Typical result}

Each colon-delimited path in the PATH is a directory where the operating system looks for commands you have entered into the system. PATH is evaluated from left-to-right, so if you have a program foobar in /opt/apps/tar-lustre/1.22/bin and also in /opt/apps/irods/2.5/bin, when you type foobar on the command line, the first one will be executed and the second ignored.

Now, let's figure which versions of a couple of common programs are seen by your PATH. Try the following:

login1$ which bash
/bin/bash
login1$ which gcc
/usr/bin/gcc
login1$ which samtools
/usr/bin/which: no samtools in (/opt/apps/python/epd/7.2.2:/opt/apps/python/epd/7.2.2/bin:/opt/apps/tar-lustre/1.22/bin:/opt/apps/gzip-lustre/1.3.12/bin:/opt/apps/intel11_1/mvapich2/1.6/bin:/opt/apps/intel/11.1/bin/intel64:/opt/sge6.2/bin/lx24-amd64:/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/gsi-openssh-4.3/bin:/usr/X11R6/bin:/opt/ofed/bin:/opt/ofed/sbin:/usr/local/bin:/sge_common/default/pe_scripts:.:/opt/apps/irods/2.5/bin)

Extending PATH

You extend your PATH by changing the PATH variable (yes, you can do that!). Try the following:

export PATH=$PATH:$HOME/bin

then echo $PATH again. If you put an executable file in your $HOME/bin directory, you will be able to run it just by typing its name.

#!/bin/bash

echo "Howdy, y'all!"

This works for other people's code too. So, you could install a copy of samtools in your $HOME/bin directory and it would show up. You won't need to do this, as we will demonstrate in the next section, but you should get the general idea.

Making it stick

Having to remember to type in export PATH=$PATH:$HOME/bin every time you start a new shell is... burdensome. Luckily, it's easy to make it semi-permanent by editing the .profile_user file that exists in your $HOME directory. If you open it in a text editor, add the line export PATH=$PATH:$HOME/bin, save, and re-login to Lonestar you will find that your PATH automatically includes $HOME/bin.

Let's move on now to the next section: The modules system