Re^2: Making File::Spec cross platform

I can think of two approaches to this.

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

Comment on Re^2: Making File::Spec cross platform

Replies are listed 'Best First'.
Re^3: Making File::Spec cross platform by Tanktalus (Canon) on May 20, 2005 at 16:09 UTC
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. 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.	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: Making File::Spec cross platform
by Tanktalus (Canon) on May 20, 2005 at 16:09 UTC

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

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.

[reply]
[d/l]