The path less traveled

Many problems encountered by new Linux users can be fixed with a better understanding of paths. The PATH environment variable tells your shell to look for the command you typed. This keeps you from having to type out the full path to a command every time. `/bin/ls` may only be 5 more keystrokes than `ls`, but after a while it really adds up. And if you have a command in a place like /opt/gempak/os/linux/bin, you really don’t want to have to type that out every time. By default, certain system paths are included: generally /bin and /usr/bin, at the least. You can set your PATH to include whatever directories you want ( ~/bin is a common addition), but you need to be careful.

I once had a user complain that some simple commands took a long time to execute. When I saw his PATH, I realized what his problem was. There were nearly a dozen directories in front of /bin, including a non-existent directory in a space that gets automounted. So when he’d type ls, the shell would go through each of those directories, and when it reached /home/cwp, it hung for several seconds while it tried in vain to mount the directory. This brings up two important points: make sure the directories in your PATH exist, and put the most frequently used directories first.

Another problem is that some packages contain programs with the same name. There’s not much you can do about that. Whichever comes first in the PATH gets executed. If there’s one that you use more than another, make sure it is toward the front of your PATH.

There’s also an environment variable called LD_LIBRARY_PATH. This comes up less often, but can be just as problematic. Many common functions are in files called libraries, that get shared by many binaries. System libraries are generally kept in /lib and /usr/lib. Many software packages have their own libraries, sometimes stored in their own lib directory. In a lot of cases, the binaries know where to look to find their library files, but sometimes they don’t. If a program complains that it can’t find some library, but you know it exists, you can set the LD_LIBRARY_PATH environment variable to point to where the libraries are located. For example, the WDSS-II radar analysis package doesn’t know to look in its lib directory, so you have to manually specify it:

setenv LD_LIBRARY_PATH /opt/WDSS2/lib

You can find out what libraries a binary needs using the ldd program:

[1013 bcotton@boone ~ ]$ ldd /usr/bin/gcc => (0x00e12000) => /lib/ (0x00489000)
/lib/ (0x0046a000)

Applications behaving badly

In my line of work, we see a lot of support tickets that go along the lines of “some application stopped working.” These can be frustrating, because the user is often more familiar with the application than you are. Fortunately, there are often some easy steps that you can take initially. Many applications store user-specific configuration information in what are known as “dot-files” — files or directories that begin with a . and live in the user’s home directory. If the application produces a dot-file, the first step you might try is to have the user rename the dot-file. For example:
mv .matlab .matlab-old
When the user launches the application again, the application will see that the dot-file doesn’t exist and create a new one.

What happens frequently is that a person reaches their quota, and the next time the application tries to write to the dot-file, it can’t and the file ends up getting corrupted. In some cases, you can recover some data from the old dot-file into the new dot-file (for example, Firefox bookmarks) by copying the appropriate file from the old to new directory. has a particular file that can get corrupted, but it can be fixed easily enough:
find ~ -name "Common.xcu"
This will give you a listing of all the files named Common.xcu in your home directory. To my knowledge, that particular filename is specific to, so you can generally do the finding and deleting in one fell swoop:
find ~ -name "Common.xcu" -exec rm {}\;
Another common problem is when environment variable aren’t set correctly. Many applications use environment variables to indicate the location of configuration and data files, and sometimes even executables. If you think an environment variable might be the cause, you can run the `printenv` command. This will give an output of the names and setting for all environment variables. Sometimes it is fairly obvious where an error is. For example, PGI might have been set to /opt/pig instead of /opt/pgi. Other times, a variable just is not set. The documentation for a particular piece of software will often list variables that need to be set.

Sometimes, the problem is that the software is being used on a platform it wasn’t designed for. Most of the computers these days have 32-bit processors, but a few have 64-bit. Sometimes, the 64-bit machines do not have the 32-bit libraries needed to run 32-bit programs (these are available through your particular package manager, like up2date or yum, but you may have to force it to use the 32-bit (a.k.a. i386) architecture). Or a person could be pointing to the wrong path. Some packages have both an i386 and an x64 (or other similarly named) directory, so it is important that the right one is specified.

Beware the Ides of March

Fellow, come from the throng; look upon Caesar.  The nugget night website has been updated with a very interesting number.  A new personal record has been set in the consumption of nuggets.  I ate 68 nuggets tonight, and I yet live.  My stomach is rather full, but I made it.  There was celebration all around.  We’ve been to 18 consecutive nugget nights now, and we’re getting to be pretty well known by the staff.  I really need a better hobby.  Pictures will be uploaded in the next day or two.