Better way to handle Unix compatibility modes must be found
John E. Malmberg wrote:
Are you going to have time to look at the patches that I submitted to
MakeMaker and Test::Simple?
These are to support VMS when the DECC$FILENAME_UNIX_REPORT and
DECC$EFS_CHARSET and related options are active.
These options make Perl on VMS look more like Unix, including returning
filenames in Unix syntax. Path tools has already been updated to work
in this mode.
I had a look at this, and I can't apply it. It was bad enough having special
case code for VMS, now there's three different styles of VMS to be considered.
Here's the mass of detection code:
use VMS::Feature;
my $vms_unix_rpt = VMS::Feature::current(filename_unix_report);
my $vms_efs = VMS::Feature::current(efs_charset);
my $vms_case = VMS::Feature::current(efs_case_preserve);
$Is{VMS_mode} = 0 if $vms_unix_rpt;
$Is{VMS_unix} = 1 if $vms_unix_rpt;
$Is{VMS_lc}= 0 if $vms_case;
$Is{VMS_noefs} = 0 if $vms_efs;
That mercifully doesn't include the work around if VMS::Feature isn't there.
There's no way to expect Perl programmers to stick all that in their code just
to accommodate VMS.
But this diff here illustrates the real problem:
-is( $mm-{INSTALLVENDORMAN1DIR}, File::Spec-catdir('foo','bar'),
+my $expect = File::Spec-catdir('foo','bar');
+$expect = VMS::Filespec::vmspath($expect) if $Is_VMS;
+is( $mm-{INSTALLVENDORMAN1DIR}, $expect,
'installvendorman1dir (in %Config) not modified' );
Now every call to File::Spec, which is supposed to generate a portable path,
has to have extra code tacked onto the end to do more work. If that's
necessary then File::Spec::VMS should be doing it.
In conclusion, this should all be built into File::Spec::VMS.
--
ROCKS FALL! EVERYONE DIES!
http://www.somethingpositive.net/sp05032002.shtml
Re: Better way to handle Unix compatibility modes must be found
Michael G Schwern wrote:
John E. Malmberg wrote:
Are you going to have time to look at the patches that I submitted to
MakeMaker and Test::Simple?
These are to support VMS when the DECC$FILENAME_UNIX_REPORT and
DECC$EFS_CHARSET and related options are active.
These options make Perl on VMS look more like Unix, including returning
filenames in Unix syntax. Path tools has already been updated to work
in this mode.
I had a look at this, and I can't apply it. It was bad enough having special
case code for VMS, now there's three different styles of VMS to be considered.
Yes there are three major sets:
1. Traditional mode which is limited in the character set available,
which includes several serious bugs in the conversion of Unix format
file specifications to and from VMS format. These bugs can not be fixed
in this mode because other programs may depend on them being present.
In several cases, the Unix file specifications produced are invalid and
can not be used, except for special VMS code that has been added to deal
with the bugs.
Some of the bugs in the traditional mode are from the assumption that
the equations ($path == vmsify(unixify($path))) and ($path ==
unixify(vmsify($path))) will always evaluate to true.
This is not the case on VMS and never has been the case for all file
specifications. The file $foo that results from $foo =
vmsify(unixify($bar)) may not even resolve to the same directory as
$bar, let alone the same file.
In short, you only want to vmsify or unixify a filespec once, just
before it is used to access a path or a file. You can not unixify a VMS
file specification with the expectation that you can vmsify it back to
the original file or the reverse.
That has never fully worked, and can not be made to fully work.
In order to use the Traditional VMS mode, Perl programs usually need to
also have VMS specific code in them.
2. Extended character set, VMS format, which requires that the bugs in
the Unix to VMS conversions not be present.
This is because with the restricted character set, the illegal Unix
names were obvious and could be handled, but with the extended character
set, those Unix names could be valid, even though they are usually not.
This exposes many cases where vmsify(unixify) or unixify(vmsify) was
being used and totally failing, since files that were previously ignored
were now being used.
A side effect of this is that VMS can preserve the case of the filename
similar to how Windows does.
Many Perl programs will now just work on VMS in this mode, unless they
have some explicit UNIX requirement.
3. Unix compatibility mode. This is where VMS both case preserves the
results, but also the library routines will returns results
There is also a mode where the VMS C library will not accept VMS syntax
filenames, but assumes Unix. I have not tried to get that mode to work.
While the Unix compatibility is not perfect, it is good enough for many
Perl scripts written with only UNIX in mind to work on VMS with zero
modifications.
While there are three main modes, there many feature settings that
control them, and each of those modes are a result of preset combinations.
It is not the case that all perl programs need to check the mode that
VMS is in. It is only a small set of perl programs.
1. Test programs that need to explicitly know what syntax a filename is
going to be.
2. Library routines that have to support the traditional VMS mode, and
should also work in the two other modes.
3. Library routines that generate scripts/makefiles or native command lines.
It the future, Perl on VMS will be optionally supporting Unix shells
like bash as a default instead of just DCL.
Here's the mass of detection code:
use VMS::Feature;
my $vms_unix_rpt = VMS::Feature::current(filename_unix_report);
my $vms_efs = VMS::Feature::current(efs_charset);
my $vms_case = VMS::Feature::current(efs_case_preserve);
$Is{VMS_mode} = 0 if $vms_unix_rpt;
$Is{VMS_unix} = 1 if $vms_unix_rpt;
$Is{VMS_lc}= 0 if $vms_case;
$Is{VMS_noefs} = 0 if $vms_efs;
That mercifully doesn't include the work around if VMS::Feature isn't there.
There's no way to expect Perl programmers to stick all that in their code just
to accommodate VMS.
But this diff here illustrates the real problem:
-is( $mm-{INSTALLVENDORMAN1DIR}, File::Spec-catdir('foo','bar'),
+my $expect = File::Spec-catdir('foo','bar');
+$expect = VMS::Filespec::vmspath($expect) if $Is_VMS;
+is( $mm-{INSTALLVENDORMAN1DIR}, $expect,
'installvendorman1dir (in %Config) not modified' );
Now every call to File::Spec, which is supposed to generate a portable path,
has to have extra code tacked onto the end to do more work. If that's
necessary then File::Spec::VMS should be doing it.
File::Spec::VMS traditionally has not generated a portable path. It
only does that now
Re: Better way to handle Unix compatibility modes must be found
John E. Malmberg wrote: It is only the case where something is building a VMS specific Make script or building a DCL command file that a filename needs to specifically be converted to VMS path syntax. Ok, then build it into the MakeMaker File::Spec overrides and use them. -- 10. Not allowed to purchase anyone's soul on government time. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: Better way to handle Unix compatibility modes must be found
On Apr 2, 2009, at 9:33 AM, John E. Malmberg wrote:
Michael G Schwern wrote:
John E. Malmberg wrote:
Are you going to have time to look at the patches that I submitted
to
MakeMaker and Test::Simple?
These are to support VMS when the DECC$FILENAME_UNIX_REPORT and
DECC$EFS_CHARSET and related options are active.
These options make Perl on VMS look more like Unix, including
returning
filenames in Unix syntax. Path tools has already been updated to
work
in this mode.
I had a look at this, and I can't apply it. It was bad enough
having special
case code for VMS, now there's three different styles of VMS to be
considered.
I had a similar reaction when I first saw it, but no one has suggested
-- much less implemented -- anything else that actually works. If you
have a better solution, please speak up.
But this diff here illustrates the real problem:
-is( $mm-{INSTALLVENDORMAN1DIR}, File::Spec-
catdir('foo','bar'),
+my $expect = File::Spec-catdir('foo','bar');
+$expect = VMS::Filespec::vmspath($expect) if $Is_VMS;
+is( $mm-{INSTALLVENDORMAN1DIR}, $expect,
'installvendorman1dir (in %Config) not
modified' );
Now every call to File::Spec, which is supposed to generate a
portable path,
has to have extra code tacked onto the end to do more work. If
that's
necessary then File::Spec::VMS should be doing it.
File::Spec::VMS traditionally has not generated a portable path.
It depends on whether portable means native to the platform you are
running on or something generic that can work on any platform.
In conclusion, this should all be built into File::Spec::VMS.
That's logically impossible, for reasons that John explained. To
simplify a bit, File::Spec can reasonably be made to know whether it's
expected to return results in native format or Unix format. It cannot
reasonably be made to know that it is being called from a spot in
MakeMaker that must produce a native format filespec that will be seen
by a native utility regardless of what mode Perl is in.
It is only a small set of Perl programs that have benefited from it
converting some file specifications to VMS format. I have found
more cases of programs that have required that VMS specific code be
added to them to compensate for this conversion in one way or
another than I have found programs actually expect it and need it to
happen.
It is only the case where something is building a VMS specific Make
script or building a DCL command file that a filename needs to
specifically be converted to VMS path syntax.
That's probably 90% true now. It was closer to 0% true in the dawn of
time, when File::Spec::VMS::catdir first returned a native format
spec. There wasn't really any choice about that at the time. The
CRTL did not understand Unix format filespecs and there were lots of
other things it didn't do that had to be implemented via native
services. There are more choices now, which does make things
complicated.
Craig A. Berry
mailto:craigbe...@mac.com
... getting out of a sonnet is much more
difficult than getting in.
Brad Leithauser
