Facebook
Digg
StumbleUpon
del.icio.usThis document is intended for the everyday user. A more thorough definition of symlinks can be found here.
Definition of a Symlink
Symlinks are the greatest thing ever. To elaborate, a symlink is a special file in a UNIX filesystem that contains no user data, but instead points to another file (or special file, such as a directory) in the system's hierarchy, or nothing at all. They are very useful in cases where something has moved, but the data still needs to be retrievable from it's old location, or where a certain file belongs in more than one place in a hierarchy.
Symlinks should not be confused with "links" from Microsoft Windows fame. "Links" in Windows are regular files that contain data that tells the Windows shell where to find a file, or a program, or whathaveyou. Without the Windows shell to parse them, they are no more than binary data; they cannot be used in the same way that a true UNIX symlink can.
Reading Symlinks
To see what a symlink points to, all that needs to be done is:
# ls -l link
In Perl, a symlink can be read with the readlink($link)
function.
In zsh, and perhaps other shells, symlinks can be globbed with
"*(@)".
A symlink's size is equal to the length of the reference string. A symlink
that points to /bin/ls will have a reported size of 7 bytes, whereas a
symlink to bin/ls will be 6 bytes. Note that this size isn't "real,"
because there are no blocks in the filesystem allocated for the symlink,
only an inode. This comes up when writing scripts and stuff, but isn't
very important for everyday use.
Accessing Symlinks
For the most part, symlinks can be accessed in the same way that a regular
file or directory would be. However, programs that crawl a tree that contains
symlinks may behave inconsistently. Also, commands such as chown
and chmod will perform their task on the entity that the symlink
points to, not the symlink itself, unless they are given the -H
option. Care must be taken when using any tool that plays with the filesystem.
Creating Symlinks
The general syntax for creating a symlink named "destination"
that points to the file "source" is this:
# ln -s source destination
The source argument requires some special attention.
ln does not check if the source file exists, or anything.
ln will eat any string as the source that is
fed to it. In fact, in FreeBSD 5, this is taken advantage of by the
malloc code. malloc can be given different
flags by changing the string that the /etc/malloc.conf
symlink contains.
The point I'm trying to make is that an absolute or relative
symlink can be made, and the type to pick depends on the situation. For
example, the symlink /usr/bin/perl is absolute, pointing to
/usr/local/bin/perl. This is because these two entities will
always be in the same absolute place in the system's heirarchy. Here's
an example absolute symlink:
# cd /home/craig # ln -s /home/craig/images/dog1.jpg dog.jpg
In the case of files that will not necessarily have the same absolute locations, such as a portable hard disk, relative symlinks are the choice to make. Note that the source file and the symlink to it must still be in non-changing locations to relative each other. Here's an example relative symlink:
# cd /home/craig # ln -s images/dog1.jpg dog.jpg
In a relative symlink, "../", or multiples of them may be placed
in the source to refer to upper directories, just like on the command line.
Removing Symlinks
Removing symlinks is easy. Usually, a simple rm symlink
will do it, but there are times when it will fail. If the symlink name
specified has a trailing "/",
rm symlink will fail with the following output:
# rm symlink/ rm: symlink/: is a directory
The solution, obviously, is to not specify the trailing "/".
Users of zsh are in luck, because zsh chops off the
trailing slash most of the time anyways.
