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

Reply via email to