At 9:15 AM -0500 8/29/07, John E. Malmberg wrote:
>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.
Is the problem specifically with rmtree(), or is the problem with
File::Find or readdir() not reporting it properly?
>Then it exposed that rename() on VMS was broken for directories.
OK, that has it's own thread, so I'll try to catch up with what's
going on there.
>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.
Well, "unexpectedly" may need a bit of qualification here. On the
face of it, returning a valid native spec should always be kosher,
and, as you note, some things -- probably a lot of things -- depend
on that. I don't know what documentation you are referring to, but I
can assure you that the expected behavior of File::Spec->catdir('foo',
'bar') is "foo/bar" on UNIX, "foo\bar" on Windows, and "[.foo.bar]"
on VMS. What would be unexpected would be if you got some foreign
format.
>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.
Again, it just doesn't pass the common sense test that returning a
valid native spec 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.
It is not easy to pick apart and reassemble filespecs in a completely
cross-platform way. A lot of scripts and modules don't even try.
Some try very hard and still don't get it quite right, often because
the authors don't have the resources to test everywhere. Some of the
special casing may not be needed anymore, but fixing it involves
rewriting stable -- and often difficult -- code without breaking
anything on multiple platforms. Sometimes special casing works
around bugs that have been fixed, but the module in question supports
older versions of Perl or other modules.
Having said all that, it is possible to do pretty sophisticated
manipulations using File::Spec without ever knowing or caring what
platform you are on or what format the pieces are in.
>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.
I don't doubt there are unhandled cases. If you are talking about
escaped characters (such as when you have multiple dots), then yes,
the File::Spec::VMS routines need some work.
>One issue is that the VMS specific File::Spec routines should never be calling
>vmsify() or unixify().
Well, they have to or a lot of things will break. Of course if you
can eliminate unnecessary conversions without changing the final
result, so much the better.
>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.
This is better now than it was for some time in the pre-5.9.5 time
frame. I fixed some bugs where escaped characters became double and
triple escaped after multiple round trips. If there are remaining
cases, let's fix them. If there are cases where it's theoretically
impossible to make the round trip, then let's document them. If
there are places where we can eliminate the round trip without
changing the final result, that's fine by me.
>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.
If you're talking about the C run-time setting
DECC$FILENAME_UNIX_ONLY, then I don't think File::Spec::VMS is what
File::Spec should invoke when that is in effect. When you flip a
switch on VMS so it can't understand VMS filespecs, then it doesn't
make a lot of sense to try to manipulate filespecs in a VMS-friendly
way. I'm not sure that $^O should even return 'VMS' in this case.
>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.
See:
http://search.cpan.org/~clane/VMS-FileUtils_0.014/safename/safename.pm
>
>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
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
