Michael G Schwern wrote:
John E. Malmberg wrote:
Michael G Schwern wrote:
<snip>
This makes File::Spec->canonpath( File::Spec->curdir ) difficult to
use as now you have to carefully distinguish between false and
undefined to see an error.
Actually that brings up a different issue that was discussed on the
vmsperl list. You see '' is a valid file specification on VMS in VMS
file spec format.
What does it mean? Is it a synonym for cwd?
No. It means "SYS$DISK:[]." which is a file with a null name and a null
extension. A period delimiter between a file and the extension is
always present.
On VMS, if you are missing a component of a filename, it will supply a
default, based on the context.
So undef is the only way to indicate an error. And it should be that
way on other platforms for consistency.
Making false or empty string a valid return value and only undef to
indicate an error makes interfaces really hard to use. File::Spec is
already really hard to use, so I'd like some way to reverse that.
But it's moot if canonpath is no longer returning [] as an empty string.
On a related note, unlike all the other File::Spec variants
File::Spec->catdir('', 'some', 'dir') does not produce an absolute
path. It does the opposite and produces a relative one. In fact, I
can't see how to make an absolute path on VMS with catdir().
You can not, you need to use catpath to make an absolute path. I do
not know if that is a bug or a feature.
So lets look on Microsoft Windows:
C:\tools>perl -mFile::Spec -e "print File::Spec->catdir('','foo','bar')"
\foo\bar
It looks to me that this is a bug. Both Microsoft Windows and VMS
have volume name components, so the routines should work similar.
At a guess I'd say it's to take into account that '' means something on
VMS. In the interest of compatibility, it should be ok to make an
exception for an empty string as the first directory in the list.
I think it would be unusual for someone to pass '' to catdir in VMS
specific code especially since currently does nothing at all.
While changing this could be seen as breaking compatibility, the
catdir() behavior is tested in t/Spec.t, these differences in
behavior add to the difficulty of writing portable code for VMS. I'd
see making writing compatible code easier a greater priority than
maintaining a historical incompatibility.
From what I have been doing to get tests to pass on VMS, I have found
that a lot of the if $^O eq 'VMS' code is to work around such
inconsistencies. How much code is really expecting them to exist is
unknown.
I was thinking more of code written by VMS natives for VMS. I think
non-natives will be quite happy of any opportunity to throw out VMS
exceptions.
Some sort of flag to tell Perl on VMS it does not need to be backwards
compatible inside of a module or a program?
I plan to start looking at these more in the future. Right now I am
fighting with getting gnu tar 1.19 to run on VMS so I can figure out
why Module::Build is not able to read a tarball that it creates using
Archive::Tar.
Ouch.
Indeed.
-John
[EMAIL PROTECTED]
Personal Opinion Only
