David Landgren wrote:
John E. Malmberg wrote:
[...]
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.
If I remember my VMS, This happens when a directory hangs of a logical
thingy, to get around the eight depth limit? Such as
sys$foo:[a.b.c]def.ghi;2
unixified might give
/usr/sys/foo/bar/rat/baz/a/b/c/def.ghi
and when vmsified you might not get back the right version and in any
event [usr.sys.foo.bar.rat.baz.a.b.c] overflows what a legal path may be?
Actually I have not seen anything overflow what a legal path may be. On
the versions of VMS that I am working on, a legal path can be 1024
characters (not including escape characters) and 4095 including escape
characters. That issue may exist on VAX.
A logical name that is expanded in the conversion from VMS to UNIX can
not always be converted back. Logical names are like symbolic links on
UNIX, with a few additional quirks, like they can have multiple
directories as targets. The translation of the logical name for a
conversion can only use the first target, which means that some files
accessible under the VMS syntax can not be if the path is converted to UNIX.
One place it tends to break is things like C<[foo.bar]xxx>, which has an
implied suffix of C<.yyy> depending on the context it is used in. There
are several others that I discovered a couple of years ago, which I
fixed in a side build of 5.8.7, but did not think to add to the self
tests. As I find them again, I will do so.
Now with ODS-5, the C<^> character is treated almost like the C<\> in a
UNIX path name. It stated that the sequence following it is part of the
name, and not a delimiter, I have not figured out how to get all the
regex code in Path tools to understand this.
The VMS C runtime as features that let me turn on support for ODS-5 and
such. Currently if I turn those features on, many things in Perl stop
working. Mostly what stops working is VMS specific code.
[...]
I don't know what the rules are for paths, but your filename munging
would look like
$filename =~ s/[0-9A-Z_-](?=.*?\.)/_/g;
I used a tr/\./_/ to fix the case that was failing. It was only dealing
with directories, so it worked. There are probably more characters that
need to be re-mapped though, so switching to what you have is probably
better. It also needs to be made case insensitive, so I need to add the
c<i> suffix.
Currently my progress is at:
[-.lib.Archive.Tar.t]02_methods.t
This was passing before my changes, so I need to find out what I broke.
I probably will not find that out before tonight.
not ok 143 - Extracted file '[.src.short]20215' exists
# Failed test ' Extracted file '[.src.short]20215' exists'
# at [-.lib.archive.tar.t]02_methods.t line 739.
not ok 191 - Extracted file '[.src.short]20215' exists
...
Several more of these are repeated.
# Looks like you failed 19 tests of 515.
[-.lib.CPANPLUS.Dist.Build.t]02_CPANPLUS-Dist-Build.t
I have not fully investigated this. What I know so far is it is failing
to find a file with a name not permitted by VMS ODS-2 syntax, and that
it is also claiming to fail to fetch a tarball through ftp or http.
[-.lib.CPANPLUS.t]00_CPANPLUS-Internals-Utils.t
not ok 4 - Cwd() is 'foo'
# Failed test ' Cwd() is 'foo''
# at [-.lib.cpanplus.t]00_cpanplus-internals-utils.t line 37.
# got: 'PROJECT_ROOT:[PERL-BLEAD.lib.CPANPLUS.t.FOO]'
# expected: 'PROJECT_ROOT:[PERL-BLEAD.LIB.CPANPLUS.T.foo]'
If I set the C library to preserve the case of files, this test passes,
so if there is a way to tell C<ok()> to do a case insensitive check on
VMS, it will be an easy fix.
It also exposes a long term issue where on VMS, perl by default returns
all file names and paths in lowercase (VMS ODS-2 stores them in
uppercase), the getcwd() routine output is not converted.
[-.lib.CPANPLUS.t]08_CPANPLUS-Backend.t
[-.lib.CPANPLUS.t]20_CPANPLUS-Dist-MM.t
[-.lib.CPANPLUS.t]21_CPANPLUS-Dist-No-Build.t
I have not investigated these failures yet.
The *_cpanplus-*.t tests on VMS have another bug that is not showing up
on the tests. Each run of them appends a string to the logical name
"PATH" and PERL5LIB.
First run:
"PATH" =
"/project_root/perl-blead/lib/cpanplus/t/../bin|project_root:[perl-blead.t]"
"PERL5LIB" =
"/project_root/perl-blead/lib/cpanplus/t/../lib:/project_root/perl-blead/lib/cpanplus/t/inc:PROJECT_ROOT:[PERL-BLEAD.
Second run:
"PATH" =
"/project_root/perl-blead/lib/cpanplus/t/../bin|/project_root/perl-blead/lib/cpanplus/t/../bin|project_root:[perl-blead.t
]"
"PERL5LIB" =
"/project_root/perl-blead/lib/cpanplus/t/../lib:/project_root/perl-blead/lib/cpanplus/t/inc:PROJECT_ROOT:[PERL-BLEAD.
lib.VMS_AXP]:PROJECT_ROOT:[PERL-BLEAD.lib]:PROJECT_ROOT:[PERL-BLEAD.T]:/project_root/perl-blead/lib/cpanplus/t/../lib:/project_root/
perl-bl"
=
"ead/lib/cpanplus/t/inc:PROJECT_ROOT:[PERL-BLEAD.lib.VMS_AXP]:PROJECT_ROOT:[PERL-BLEAD.lib]:PROJECT_ROOT:[PERL-BLEAD.T]"
Thanks,
-John
[EMAIL PROTECTED]
Personal Opinion Only