Once you put your paths together, you can use the abs_path() function from the Cwd module. It does what you want with the relative path and symlinks.

This needs to work on (at least) Win32 and *nix. When this path is fed to Cwd::abs_path() on a MSWindows system the dir separator will be '\'. I was under the impression that Cwd only dealt with '/' as a separator. Am I mistaken? What about the (hypothetical and increasingly unlikely) scenario where I want this to also work under a pre-OSX MacOS whose separator is ':'?

--DrWhy

"If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."

$ ls; echo -----; ls d/..
d
-----
b
[download]

So how would you clean up this path? ;-)

Yes, I've produced a pathological case: in /tmp/a/b/c, I created a symlink d -> .. - thus d/.. really is ../.. and we get the wierd output. However, I have similar structures of links going all over the place where we actually rely on this type of behaviour, otherwise we couldn't do what we wanted at all. So I'm quite glad File::Spec behaves as it does on Unix.

In my mind, then, File::Spec already is cross platform in that it works on all platforms as well as it can without sacraficing accuracy. That's perfect for me.

I can think of two approaches to this.
1. resolve paths with /../ in Unix by actually walking the directory tree and resolving symlinks as they are arrived at. If at some point you find that your path doesn't match the correct system then you revert to the behavior of the other File::Spec::<OS> modules which operate without reference to what is actually on the filesystem.
2. Just do the clean up without referring to the file system, without respect to the possibility of symlinks in your path. The other OS's versions of canonpath (as I just mentioned) actually behave this way -- they don't care if your path really exists on the current system or not -- they're just doing string manipulation.

Either solution would have to be implemented by adding a new method to File::Spec to preseve existing functionality. This method would just be a synonym for canonpath in most File::Spec::<OS> modules, being different only for the Unix one.

--DrWhy

"If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."

1. According to the File::Spec docs, which say:

   No physical check on the filesystem, but a logical cleanup of a path.

   you would be breaking the promise that this is as good as it gets without touching the filesystem.
2. The other OS's don't need to worry about symlinks - thus "d/.." is always the same as ".". That's why a string manipulation works. On Windows, I don't need to check the filesystem to know that "a\b\c\d\.." is always always always the same as "a\b\c". On Unix, I can't make that guarantee.

So your answer is to create a new function, obviously with different documentation. Your option 2 is going to get all the unix zealots (where "zealot" is defined as "someone who cares about accuracy) to cry "don't use it!" to anyone asking about it. That's just not going to be an option for something that is part of the core distribution: above all, it must be reliable and accurate. (That's not to say everything in the core is reliable and accurate, but, so far, File::Spec is that, so we don't want to make it worse.)

Your option 1 is the only reasonable approach in my opinion. But I'm not sure how complex this really is:

use Cwd;
our *abs_path = Cwd::abs_path;
[download]

Put those two lines in File/Spec.pm, add some documentation, and I think we're done.

I like that File::Spec doesn't touch the filesystem. I like that Cwd does. I'm not sure where the advantage of mixing these together is off-hand.

That is the beauty of open source eh? That you can implement this yourself!

I feel like this is a good idea, because you can produce the symbolic-link checks needed to be sure that this would work in the special cases you forsee. Your new function could act as a preprocessor (wrapper) for canonpath, performing the checks for symbolic links as would be required, and then send your string on to canonpath and returns its results. There is no need to reproduce the work already done there...

I think this is a great idea! I am sure that the autor would accept such a patch, as it does not intefere with what is already there.