Ken Williams wrote:
Hi John,
Thanks for the patch, I've applied it. Could I trouble you to also add
a few tests to Spec.t to exercise these dead bugs?
Someone already did with a recent change to Spec.t, which made them show
up as failed at the same time I made a significant change to vms.c, so
I had to chase down what happened. Now I can test my change to vms.c again.
Fortunately I also had fixes to at least one of them from my mutant
version for OpenVMS support of symbolic links.
These bugs would also show up when I put the CRTL in UNIX compatibility
mode from running other tests.
Or do you want some tests to expose the bugs in processing '^'
characters in OpenVMS file specifications? Those file specifications
will not exist on the VAX platform, so it may not be appropriate to run
the tests on them.
By the way, canonpath('./') on OpenVMS returns '[]' instead of a UNIX
format string. I have not had time to test what a real UNIX/LINUX
system is expected to return.
I have been trying to get the fixes in before I update the tests to
expose things that I have found are broken. Maybe I should put the
tests in first?
Proper functioning of lib/File/Spec/VMS.pm and CWD.pm require that they
know what mode that the OpenVMS CRTL is in for handling UNIX format file
specifications and ODS-5 extended character sets.
As of yet, no method other than looking at $ENV{'DECC$xxxxx_xxxx_xxxx'}
values (which may not be 100% accurate) has been created. And I have a
backload of fixes that require this for Perl programs.
Right now, I am trying to teach vms.c/vmsish.h how to handle filenames
longer than 256 characters, which have existed on 64 bit versions of
OpenVMS for awhile.
Also food for thought: OpenVMS file specifications in UNIX format can
contain UNICODE file specifications, which I think means some flag needs
to be set on the Perl internal storage in some cases. Having not worked
with UNICODE directly, I am not sure of all the impacts of this, or if
there is much need for OpenVMS Perl users to support UNICODE filenames.
Thanks,
-John
[EMAIL PROTECTED]
Personal Opinion Only.
