Craig A. Berry wrote:
At 7:17 PM -0500 9/11/07, John E. Malmberg wrote:
Carefull, even though readdir() will only return "." when it means ".;",
it is very likely that updir() may return "." instead of "[]" in the
future for VMS. A
Hopefully not as long as $^O eq 'VMS' is true. We probably need
something more radically different to handle higher levels of UNIX
emulation. Remind me to study the differences between the Cygwin
port and the Win32 port.
If there was a way to dynamically change $^O, it would be one thing, but
from previous conversations on this list, such a way has not been found.
What I do not want is to have two different distributions to keep track
of and apply patches to. I think it is far too much trouble.
My investigation so far indicates that the vast majority of the issues
needed to get the UNIX mode to work as expected for the perl scripts
that I have been finding in the wild, are also problems with perl
running in VMS mode. Most notably handling the extended character set.
Right now, only a few modules like File::Spec::VMS, Makemaker, and some
of the tests really need to know what mode that the VMS and the C
library are in.
And most of those changes are in getting the extended character set to
work. Getting multiple dots in directories and filenames to work is the
big one.
And the Makemaker stuff really needs to be keying off of the C<make>
program in use instead of of $^O eq 'VMS'.
I am not sure what the differences are between the Win32 and Cygwin
port. There is also a UNIX services for Windows, and there was an MKS
POSIX subsystem available, and I do not know if either variant of Perl
can deal with those. I do not know if the MKS POSIX subsystem is still
available.
There are likely a lot of VMS issues that are also Win32 issues.
Handling UTF-8 filenames may be one of them. ODS-5 was developed to
hold Unicode filenames in UCS-2 format externally to be compatible with
Win32. It was a side effect that that UTF-8 filenames also can be
stored on ODS-5.
ODS-5 considers a filename in UTF-8 and UCS-2 to be two different names
and does not automatically convert them. The C library also can not
handle UCS-2 names. VMS only displays UCS-2 names in native form after
encoding them into VTF-7.
This has created an issue with porting UNIX applications to non-english
variants of VMS because the existing UCS-2/VTF-7 filenames are are not
accessible, and the newly created UTF-8 files are not understood by them.
I suspect that Win32/Cygwin can also store UTF-8 format files as UTF-8,
as it looks like Windows uses wide routines to handle UCS-2 names.
So does that mean that the UTF-8 names are only displayed properly by
some applications on Windows? Or that UCS-2 names are invisible to some
applications ported from Windows?
My current strategy is to:
1. get blead to pass all tests in traditional VMS mode.
2. to get the EFS character set enabled mode to pass all tests
3. and then to get the UNIX report mode to pass all tests.
3a. Try to remove as many skips and todos for VMS as possible.
From past experience, step 2 will be the hardest, next hardest will be
step 1, and step 3 is really almost trivial.
I am tempted to add a step 4, which is to add support for the wide
filename routines in win32 so that they also work on VMS, but that is
really too far in the future.
-John
[EMAIL PROTECTED]
Personal Opinion Only
