/bin considered harmful
By Chris Quenelle on Jun 19, 2006
One day the title of this blog is going to be a complete non sequitur. But the old fogeys are not all dead yet. ;-) I got bitten by a gaim bug when I upgraded my Solaris desktop recently, and the problem could potentially affect many applications, so it's something to be aware of. Many applications need to look for helper files in a lib directory someplace, and many of those applications are coded in such a way that they will helpfully look in a location relative to where the binary resides on your disk.
For example, gaim will look ../lib for its library files. This is great if you run /usr/bin/gaim, because it will look in /usr/lib/gaim. But if you run /bin/gaim, it won't find any gaim helper files in /lib. Worse, it might even hang if it tries to search /shared instead of /usr/shared. /shared is an automounted directory inside Sun's network, and not all the automounted hosts are up all the time.
The workaround for this problem is easy. Make sure /bin is not on your search path, or else make sure it shows up after /usr/bin. That means when you run 'gaim', the shell will run /usr/bin/gaim instead of /bin/gaim.
One reason for this problem is because /bin is a symlink to /usr/bin, but /lib is not a symlink to /usr/lib, this opens the door to implementation inconsistencies. Before Solaris 10, both /bin and /lib were symlinks. File symlinks have some of the same problems, and Unixen work around this by using hard links instead of symlinks. Unfortunately you can't easily use hard links for directories.
There are many ways that a program can find out where the currently running executable lives on the disk, and there are some subtle differences depending on which algorithm you use. Also, many of the mechanisms you might want to use are not portable across both Solaris and Linux (and/or other posix-style UNIX systems).