Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a script for building a particular flavor of GCC cross-compiler. Throughout the script there are many paths that are not in canonical form, such as duplicate path separators (/xxx/foo//bar/yyy) and intervening "this" directories (/xxx/foo/./bar/yyy).

I was about to canonicalize all of them, but I wonder if these forms are significant rather than just a case of the script not being cleaned up. In addition to the forms just mentioned, I am also curious whether including an "up directory" in a path can also be significant in any particular situation (ie. "/xxx/foo/../bar/yyy instead of /xxx/bar/yyy). For example, I came across a path like /xxx/foo/.//bar/yyy.

The only potential situation that I can think of is when links are involved. I can imagine that the .. form might behave differently, but how about the other two forms above?

Perhaps there is also platform-specific reasons for constructing paths in this way..?

share|improve this question
A bit off topic though, but Rsync uses dir1/./dir2 to limit relative paths. The manual page contains more information at the --relative option entry. Only the structure following the dot will be transferred to the destination side. – lgarzo May 31 '12 at 16:19
For double slashes (foo//bar), see How linux handles multiple path separators (/home////username///file) – Gilles May 31 '12 at 22:58

/./ you should always be able to collapse to /.
// should usually be collapsible, BUT I have seen configure scripts check it so I assume there could be systems where it's not the same. Check it, but it'll probably be fine.
/../ will only work if the preceding directory is not a symlink (or, I believe, a hardlink). Since .. is a hardlink to its parent directory, it will go up to that branch, not the one in the textual path you use. (N.B. Your shell may be set to not resolve symlinks on cds, in which case it'll go down into the directory where the symlink is; this behavior is, however, almost entirely limited to cd within shells with this option set.)

Use readlink -f "$path", I believe it will resolve all those cases properly.

share|improve this answer
At least on Linux extfs, hardlinks cannot point to directories. ln -P target linkname for a directory target yields *ln: 'target': hard link not allowed for directory. It would seem to be a more general problem; where would the .. entry in target point to? – Michael Kjörling Jun 1 '12 at 8:32
The man page says as much (though root can try). I've always assumed .. is technically a hard link but is handled specially, but "hard link" may not be the technically correct term for it. And in your example, you can't have a directory without .. so you couldn't do it manually like that (thus, special handling, also necessary for removal). But it would be conceptually something like mkdir folder; cd folder; ln -P ~- .. – Kevin Jun 1 '12 at 13:12
As I understand it, the .. entry has the inode number of the parent directory. If it does, then a directory can only have one parent directory, although in principle, I suppose it could exist in multiple places (more than one directory entry with the inode number of the target directory). That still leaves the problem of cd into it, then cd ..: how to guarantee consistency in that case if (multiple) hardlinks to directories are allowed. With symbolic links, this does not present a significant issue. – Michael Kjörling Jun 7 '12 at 7:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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