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
