It sounds to me like the basic idea of soft/symbolic links compared to shortcuts (on a PC) or aliases (on a Mac) are the same thing. Am I way off? Are they similar?


The basic idea is about the same. A symbolic link is a special file that contains a path (relative or absolute) to another filesystem object. In UNIX/Linux, the OS itself processes the symbolic link, resolving to the real object transparently.

On Macs, an alias seems to be a special Finder construct can reference remote objects as well as local ones, but Finder resolves the reference, not the OS. MacOS X also has symbolic links, but they are separate from aliases.

The big difference is between a Windows shortcut and a symbolic link. A Windows shortcut cannot easily replace a program because Windows always has to have these pesky file extensions and a "lnk" file is not an executable when it comes to Windows. Within the GUI, it works, but from a server standpoint, it barfs. Same with a directory. They are useful, but do not have anywhere near the power and flexibility of a symbolic link.

  • "Same with a directory": Do you mean that one cannot cd in a symlink pointing to a directory? – dash17291 Jun 22 '13 at 18:40
  • 2
    Meaning that you cannot cd to a shortcut on a Windows system since it is a Windows construct, not DOS. With UNIX/Linux, it is a filesystem construct, so it will work anywhere, including the cd command - it is up to the command to interpret the end point, not the OS. For example, cd could use a symlink to a directory, but it would properly fail on a symlink to a regular file. – Arcege Jun 22 '13 at 18:47

Not really. There is a resemblance, but only up to a point. I have known people to think “ok, symlinks are like shortcuts, but I don't quite understand them” up to the point when they said “oh, actually symlinks are not like shortcuts, and now I understand them”. So I think shortcuts are not a good way to understand symbolic links and I recommend to clear your mind of the comparison with shortcuts.

A symbolic link indicates the name of another file. That's "name" as in the full path, i.e. potentially including a directory part as well as the name inside the directory. The path can be absolute (/foo/bar) or relative (foo/bar or ../bar or just bar); if the target is given by a relative path, it's interpreted relative to the directory containing the symbolic link. The target file may or may not exist, and removing, moving or creating the target file will not affect the symbolic link.

Operations that act on the file's content act on the target file. Thus when you read or write to a file through a symbolic link, or execute a program through a symbolic link, it's as if you were accessing the target file. Operations that act on a file from the outside, such as renaming or deleting, act on the symbolic link itself. Note that for writing, it makes a difference whether you overwrite the existing file (which will act on the target) or remove the existing file and create a new file (which will leave the target intact and create a new file replacing the symlink, unless the application takes care to follow the link (many do)).

  • 1
    A symbolic link doesn't always constitute a full path: on my Slackware 13.1 system, /usr/lib/libXv.so is a symbolic link to libXv.so.1.0.0 . No full path there. – Bruce Ediger Jan 21 '12 at 19:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.