One feature of (a.k.a. symlinks ) is that unlike hard links, you can use symbolic links to link directories as well as files. Since symbolic links can span between filesystems, this can become enormously useful.
For example, sometimes administrators want to install a package in a directory tree that's different from where users and other programs expect it to be. On our site, we like to keep /usr/bin pure - that is, we like to be sure that all the programs in /usr/bin came with the operating system. That way, when we install a new OS, we know for sure that we can overwrite the entirety of /usr/bin and not lose any "local" programs. We install all local programs in /usr/local .
Thepackage poses a problem, though. X11 programs are expected to be installed in /usr/bin/X11 . But X isn't distributed as part of our OS, so we'd prefer not to put it there. Instead, we install X programs in /usr/local/X11/bin , and create a symbolic link named /usr/bin/X11 . We do the same for /usr/include/X11 and /usr/lib/X11 :
By using symlinks, we can have it both ways: we installed the package where we wanted to, but kept it invisible to any users or programs that expected the X programs, libraries, or include files to be in the standard directories.
Directory links can result in some unexpected behavior, however. For example, let's suppose I want to look at files in /usr/bin/X11 . I can just cd to /usr/bin/X11 even though the files are really in /usr/local/X11/bin :
But when I do a pwd , I see that I'm really in /usr/local/X11/bin . If I didn't know about the symlink, this might be confusing for me:
Now suppose I want to look at files in /usr/bin . Since I did a cd to /usr/bin/X11 , I might think I can just go up a level. But that doesn't work:
What happened? Remember that a symbolic link is just a pointer to another file or directory. So when I went to the /usr/bin/X11 directory, my current working directory became the directory /usr/bin/X11 points to, /usr/local/X11/bin .