File::Spec(::Unix) eludes me.

[Dale Wiles]

I'm trying to use the File::Spec module under Linux to make my code
more portable. However, it seems to have a non-intuitive handing of
the "up directory" string (".." under Unix.)

This first example is from the Perl 5.8.6 source code, so this is
the way it's "supposed" to work:

perl -MFile::Spec -e \
'print File::Spec->canonpath("///../../..//./././a//b/.././c/././")'

or using my simpler "/a/b/../c":

yields -> '/a/b/../c'

Isn't that better expressed "/a/c"?

The same thing happens with rel2abs (also from the Perl source):

perl -MFile::Spec -e \
'print File::Spec->rel2abs("../t4", "/t1/t2/t3")'

yields "/t1/t2/t3/../t4"

Again, why isn't this "/t1/t2/t4".

And lastly, the docs for no_upwards() say: "Given a list of file names,
strip out those that refer to a parent directory."

All 3 of "..", "../" and "../foo" refer to the parent, but:

perl -MFile::Spec -e \
'print join(":", File::Spec->no_upwards("..", "../", "../foo"))'

yields -> "../:../foo"

Isn't this just wrong?

I know how to write code that gives me the results I expect, but I find
the existing results wildly non-intuitive. Can anyone shed any info as to
why "/a/b/../c" is preferable to "/a/c"?

Dale Wiles

 

[J. Gleixner]

I'm trying to use the File::Spec module under Linux to make my code [...]
Isn't this just wrong?

I know how to write code that gives me the results I expect, but I find
the existing results wildly non-intuitive. Can anyone shed any info as to
why "/a/b/../c" is preferable to "/a/c"?

Check the documentation for File::Spec:

"cannonpath()

Note that this does *not* collapse x/../y sections into y. This is by
design. If /foo on your system is a symlink to /bar/baz, then
/foo/../quux is actually /bar/quux, not /quux as a naive ../-removal
would give you. If you want to do this kind of processing, you probably
want Cwd's realpath() function to actually traverse the filesystem
cleaning up paths like this."

 

[Paul Arthur]

I know how to write code that gives me the results I expect, but I find
the existing results wildly non-intuitive. Can anyone shed any info as to
why "/a/b/../c" is preferable to "/a/c"?

Sure. As an example: I have a directory '/usr/local/foo' and a
symlink '/home/bar/foo/' -> '/usr/local/foo'. Given the path
'/home/bar/foo/../baz', what directory does it point to?