5

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

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
Cross Compilereror
  • 51
  • 1
  • 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)](http://unix.stackexchange.com/q/1910) – Gilles 'SO- stop being evil' May 31 '12 at 22:58

1 Answers1

2

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

Kevin
  • 40,087
  • 16
  • 88
  • 112
  • At least on Linux ext*fs, 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? – user Jun 01 '12 at 08: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 01 '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. – user Jun 07 '12 at 07:57