extutils (Makemaker) changes.

John E. Malmberg · *nix forums Guru Wannabe Joined: 30 May 2005 Posts: 264

I have not tested this or anything on 5.8.7, I am in the process of
moving my changes over to 5.8.7.

I have seen no changes in 5.8.7 from the files I started with on my
5.8.6 basis.

These changes should be at most harmless until the rest of the VMS Perl
catches up with them, or at worse, Perl really does not function well if
you put the CRTL in the UNIX modes now.

lib/extutils/command/mm.pm

When VMS CRTL is in UNIX mode, some names need to be returned in UNIX
format.

lib/extutils/liblist/kid.pm

When the CRTL is in UNIX mode, the VMS specific code in this facility
expects these filenames in VMS format.

lib/extutils/command.pm

When the VMS CRTL is in UNIX mode, Perl needs to use '?' for a wild
card. A '%' character can occur in a filename in on ODS-5 volumes in
that mode. The UNIX 'foo%bar' is translated to the VMS 'foo^%bar.'.
Of course this will cause problems because with out any path specifiers,
a translation routine like UNIXIFY or VMSIFY does not know which way to
interpret the file.

Note, if all my patches get in, '^' in a filename will make Perl on VMS
assume that it is VMS a VMS file specification. Not the best check as
vms 'foo^^bar.' translates to a UNIX 'foo^bar', and a VMS 'foo^bar.'
translates to a UNIX filename of 'foo' . 0xba . 'r'. Also in my
examples, the trailing dot on the VMS style names is intentional and not
a typo. So perfection at guessing what operating system a file name is
for is not possible.

Even with my changes to the VMS specific part of Perl, there are still
bugs in the handling of EFS filenames. I was mainly concerned with
getting the most common cases working. I did not investigate if any
changes are needed to get UNICODE filenames translated from UNIX to VMS.

lib/extutils/manifest.pm

When the VMS CRTL is in EFS character set (ODS-5 file system), the extra
dot characters are legal if UNIX path specifications, and should not be
mangled into '_'. The DECC$EFS_CHARSET feature controls this.

When the VMS CRTL is in a case preserved mode, you should not lower case
filenames.

lib/extutils/mm_unix.pm
lib/extutils/mm_vms.pm

Starting to get into the *FUN* part. When using MMK/MMS, while they
will take UNIX file specifications as long as everything in a dependency
rule is in UNIX, some of the actions may require traditional VMS
filenames as parameters.

Not here with this patch, but when the environment variable for the
shell is "BASH" and GNU MAKE is the make program, all file
specifications will probably need to be in UNIX for the same reason,
even on VMS. It might even be safe to assume that any make program
other than MMK/MMS on VMS will want all output files names in UNIX
format. I did not work on anything other than the MMK/MMS on VMS case.

Normally what is expected is that if you put in UNIX name to a CRTL or
Perl routines, you get output in UNIX. And putting in VMS got you a VMS
name in response.

And with no options set, routines that just return filenames returned
them in VMS format.

When the CRTL is in the UNIX mode, or the coming POSIX mode, by default
it returns filenames in UNIX format, not VMS.

Before my changes, Perl was not consistent about this, and was sometimes
returning VMS specifications or UNIX specifications when under the
normal rules the other would be expected.

But when the CRTL is in UNIX or POSIX mode, things have to work
consistently. That is because it is not possible to always translate a
VMS file specification to it's equivalent UNIX pathname and then get
back the original VMS file specification.

Several VMS file specifications for different files will syntactically
translate to the same UNIX specification because of differences in the
naming conventions between the two platforms, and for the reasons that I
wrote about above.

And the cases this shows up in are a lot. So generally you can only get
away with translating the file one way, and leaving it that way. Even
though my changes make things better on translations, I know that I do
not have it as good as it could be.

So the basic rules are:

I can always come up with a valid and unique VMS file specification for
an UNIX path name to an existing file.

I can not always come up with a unique UNIX file specification for an
existing VMS file, but I can usually come up with a good enough one.

And if the file from the UNIX pathname does not actually exist, I can
not accurately predict what VMS file specification it will end up with.

And I can only guess if I have a VMS or UNIX file specifications unless
I artificially restrict what is valid in each of them.

[Some of this note should get into the VMS specific Perl programming help]

The result of this is that any code that assumes that it will see a VMS
file specification returned when it did not specifically ask for a VMS
file specification, or it started out with a UNIX file specification
will not work.

Normally what is expected is that if you put in UNIX name to a CRTL or
Perl routines, you get output in UNIX. And putting in VMS got you a VMS
name in response.

So in order to get the tests to work with MMK, I had to make sure that
all filenames were output as VMS.

I also had to make sure that MCR only gets a VMS pathname, however it is
probable that the MCR prefix can just be removed in most cases, and the
existing VMS Perl code will do the right thing.

Now of course some of the tests needed to be fixed to work in the UNIX
mode and the new POSIX mode on VMS.

wb8tyw@qsl.net
Personal Opinion Only

Google