On Wed, Sep 26, 2012 at 03:30:50PM +0100, Jon Fairbairn wrote:

I have an application where I want to use relative paths in symlinks (so that rsyncing to a different machine with a different root directory produces something with the same effect).

So I want

makeRelative "/var/www/this_server/foo/bar/" "/var/www/this_server/bob"

to return "../../bob" (which would then be used to create a symlink) so that if I copy the tree below /var/www/this_server to /var/www/that_server (perhaps on a different machine, but copying the symlinks without rewriting them), the symlinks point to the same files.

On posix at least, this would permit isRelative (makeRelative a b) always to be True, which is a pleasant property for it to have.

Is there any reason that System.FilePath.Posix.makeRelative should not do this? I don’t know enough about non-posix filesystems to know whether it even makes sense elsewhere.

Coincidentally, I needed this yesterday, was also surprised to find it missing, and wrote: makeRelativeTo :: FilePath -> FilePath -> FilePath this `makeRelativeTo` that = directory thisFilename where (thisDirectory, thisFilename) = splitFileName this thatDirectory = dropFileName that directory = joinPath $ f (splitPath thisDirectory) (splitPath thatDirectory) f (x : xs) (y : ys) | x == y = f xs ys f xs ys = replicate (length ys) ".." ++ xs (in my case, I know that both paths are absolute). One thing I wasn't sure of is what to do about different drives on Windows. Perhaps it would actually need to return a Maybe FilePath? Thanks Ian

Jon Fairbairn writes:

So I want

makeRelative "/var/www/this_server/foo/bar/" "/var/www/this_server/bob"

to return "../../bob"

[...]

Is there any reason that System.FilePath.Posix.makeRelative should not do this? I don’t know enough about non-posix filesystems to know whether it even makes sense elsewhere.

I don't know whether this might the reason (or whether it is relevant at all for the API at hand) but you can't implement this function properly w/o turning it into an IO action, since you need to be able to introspect the filesystem, because under POSIX at least, you can easily construct a filesystem, which exhibits the following confusing behaviour: ,---- | /tmp/xxx$ pwd | /tmp/xxx | /tmp/xxx$ ls -l bar | total 0 | -rw-rw-r-- 1 hvr hvr 0 Sep 28 22:03 this_is_in_xxx | /tmp/xxx$ cd bar | /tmp/xxx/bar$ ls -l | total 0 | -rw-rw-r-- 1 hvr hvr 0 Sep 28 22:03 this_is_in_xxx | /tmp/xxx/bar$ ls -l ../bar | total 0 | -rw-rw-r-- 1 hvr hvr 0 Sep 28 22:03 this_is_in_xxx | /tmp/xxx/bar$ cd .. | /tmp/xxx$ cd zoo | /tmp/xxx/zoo$ pwd | /tmp/xxx/zoo | /tmp/xxx/zoo$ ls -l ../bar | total 0 | -rw-rw-r-- 1 hvr hvr 0 Sep 28 22:03 this_is_in_foo `---- this is simply because '/tmp/xxx/zoo' is actually a symlink pointing to a different folder '/tmp/foo/zoo', whose parent contains a different 'bar' folder. I.e.: ,---- | $ ls -lR /tmp/foo /tmp/xxx | /tmp/foo: | total 0 | drwxrwxr-x 2 hvr hvr 60 Sep 28 22:03 bar | drwxrwxr-x 2 hvr hvr 40 Sep 28 22:02 zoo | | /tmp/foo/bar: | total 0 | -rw-rw-r-- 1 hvr hvr 0 Sep 28 22:03 this_is_in_foo | | /tmp/foo/zoo: | total 0 | | /tmp/xxx: | total 0 | drwxrwxr-x 2 hvr hvr 60 Sep 28 22:03 bar | lrwxrwxrwx 1 hvr hvr 10 Sep 28 22:04 zoo -> ../foo/zoo | | /tmp/xxx/bar: | total 0 | -rw-rw-r-- 1 hvr hvr 0 Sep 28 22:03 this_is_in_xxx `---- thus, | makeRelative "/tmp/xxx/zoo" "/tmp/xxx/bar" would return "../bar" which when passed to filesystem related system-calls (assuming CWD is /tmp/xxx/zoo) wouldn't point to "/tmp/xxx/bar" but rather to "/tmp/foo/bar" instead. cheers, hvr