Craig Berry wrote:
On Wednesday, April 11, 2007, at 09:48AM,\
"John E. Malmberg" <[EMAIL PROTECTED]> wrote:
VMS does not enforce executables having .EXE extensions.
True, but flouting the convention does seem like asking for trouble.
The test harness for VMS runs a perl binary with the name
"dev:[dirs]PERL." or "/dev/dirs/perl" which the above code will not handle.
It doesn't anymore. It used to, probably because a hundred years ago
> there were things in the test suite that depended on finding a file
named simply "perl" in the t directory, but the test infrastructure
> is much better now, and there was no good reason I could think of not
> to follow the local convention, so we now keep the extension when we
> copy the executable to [.t].
The old method exposed a bug in the VMS to/from UNIX filename conversion
where the trailing "." was not being handled properly. That bug did not
show up unless the DECC$ feature settings were set to enable filenames
reported in UNIX.
I can not test this right now, but I suspect if you remove the VMS
specific code above, then it should just work for all cases on VMS.
It doesn't. The code to paste on an extension could probably be made
better but isn't a priority.
Can you come up with a case where it is needed? That would probably
indicates that something in VMS.C is still not quite right.
It seems I will have a lot to catch up on when I power up my home VMS
machines again.
On VMS the image name returned by $X will always be usable as-is and
never needs a .EXE appended to it.
The code in question is a fallback and is only used if two or three
> other methods for locating Perl fail. The first thing it tries is
> $^X and checks if it's considered an absolute file spec. It clearly
> is, so why that didn't work is of more interest than any discussions
of extension pasting.
Some versions of the VMS CRTL return invalid strings for argv[0] when
the CRTL is in filename report UNIX mode. I think I put code in VMS.C
to detect and compensate for that.
> Sorry, it's not a fallback. It pastes an extension on all the
candidates (including the fallbacks) and does not allow for a case
> where there is no extension on the executable or the extension is
> different from the conventional one. Not sure what the rationale
> is for that, but that situation is unlikely to occur in the wild
> and now no longer occurs in the core test suite.
The case where $X will be path/perl is already showing up in the wild
where Perl is being invoked from the GNV bash shell.
Any code that is adding a .EXE to $X when it is missing on VMS is most
likely broken.
Building SAMBA V4 on VMS requires running Perl under GNV Bash. Several
other open source tools seem to also have this requirement.
-John
[EMAIL PROTECTED]
Personal Opinion Only
