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..?


/./ 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.

  • 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? – a CVn 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. – a CVn Jun 7 '12 at 7: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.