Can non-canonicalized forms of filesystem paths be significant? (eg. “foo//bar”, “foo/./bar”, and “foo/../bar”)

filenamesfilesfilesystemspathsymlink

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

Best Answer

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

Related Question