I have been working on trying to get the CPANPLUS tests to pass on VMS.
Right now 04_cpanplus-Module is failing for at least the following reasons:
rmtree() is broken on VMS as it can not handle a file named '.;'. This
is noticed because a bug somewhere else in it is creating that file.
I have a tentative patch for it that I do not have time to submit at the
moment. It involves special case deleting that file if it is found
right after it shows up from the readdir() command.
Then it exposed that rename() on VMS was broken for directories. I also
have a tentative patch for that.
Neither patch has been fully tested yet.
The next set of failures are a result of several problems:
The file:spec routines are basically broken on VMS when given UNIX
pathnames as input.
One of the problems with them is that several of them are unexpectedly
returning VMS format files, even though the documentation implies that
they should not be. Unfortunately fixing that is a problem as it
appears MakeMaker and other modules are dependent on this behavior,
usually in a VMS specific section.
Leaving it as is though is also a problem because unless the code
calling the File::Spec routines is special cased on VMS it will
typically break the perl script. So while this is fine for modules that
have previously been debugged for VMS, it still is basically broken
behavior.
It was also noticed on a previous thread about Archive::Extract that on
Microsoft windows, one of the File::Spec routines was also returning an
incorrect result by unexpectedly translating one of the returned
components into a native path when given a UNIX input. They are also
returning incorrect results on VMS, which results in another set of
special case conditions, the very thing that they are supposed to be
preventing.
The other problem is that on VMS the File::Spec routines are simply
returning wrong results when given a number of UNIX format pathnames.
Module Extract is producing a sample of this when untaring the file for
test 54 of the above.
One issue is that the VMS specific File::Spec routines should never be
calling vmsify() or unixify(). These routines are not reversible, even
if they make some cases of parsing more convenient, there are a number
of VMS path specifications that can not make the round trip intact.
VMS has a mode (and has had it for a long time) where it will cause
programs written in C to only see UNIX file specifications. Currently
many portions of Perl are failing in this mode, most often because
File::Spec is unexpectedly converting the file specification back to VMS.
The next issue that comes up is that there is a path specification in
the tar archive for the test that has multiple dots in it. Currently
the File::Spec routines can not deal with that, as they are using an
obsolete parsing algorithm.
This is also a problem on VAX which can not handle the resulting directory.
What is needed is a routine or regex that converts such a path name to a
format acceptable for VMS ODS-2 volumes, that is replacing the "."s with
an "_".
Some where along the line a similar routine will likely be needed to
covert things like foo.bar.xyz to foo_bar.xyz.
My current plan of attack is not to go after the swamp of changing
File::Spec now, but continue to add special cases to the routines
affected by it for VMS.
But eventually I will need to get all of these things fixed.
Any suggestions or help would be appreciated, particularly with
algorithms to handle the conversion of paths and filenames with multiple
dots (or other characters not in [A-Z][0-9][\-\_] in them.
-John
[EMAIL PROTECTED]
Personal Opinion Only
