Andrew Black wrote:
Craig A. Berry wrote:
At 9:57 AM +0000 2/28/07, Andrew Black (delete obvious bit) wrote:
Hi
A quick progress report. I worked out roughly what is going on but
hadnt
had time to write up in more detail. I am now on holiday and don't have
access to the machine at work.
It is doing funny things with path names. I have added some diagnostics
and it is trying to add .exe to perl.;1
The regexp seems to handle the ;1 but not the .;1
******* $thisperl=disk:[scratch.perl595.][t]perl.;1
******* $thisperl becomes disk:[scratch.perl595.][t]perl.;1.exe
print STDERR "******* \$thisperl=$thisperl\n" ;
if ($proto->os_type eq 'VMS') {
# VMS might have a file version at the end
$thisperl .= $exe unless $thisperl =~ m/$exe(;\d+)?$/i;
} elsif (defined $exe) {
$thisperl .= $exe unless $thisperl =~ m/$exe$/i;
}
print STDERR "******* \$thisperl becomes $thisperl\n" ;
VMS does not enforce executables having .EXE extensions.
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.
The trailing period on the filename is significant for the VMS format
and should not be present for the UNIX format. In VMS format, it
indicates that there is no file type present, so not to assume a default
extension of .EXE .
The above code appears to be wrong in that if the image name for the
running perl does not have a .EXE extension, it will always generate the
wrong answer, and will only work the existing image has the .EXE
extension, where the above code is not even needed.
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.
On VMS the image name returned by $X will always be usable as-is and
never needs a .EXE appended to it.
-John
[EMAIL PROTECTED]
Personal Opinion Only
