On Wed, Aug 28, 2002 at 09:25:02PM -0400, via RT wrote:
Show quoted text>
>
> This message about PerlIO-gzip was sent to you by DAVIDH via rt.cpan.org
>
> Full context and any attached attachments can be found at:
> <URL:
https://rt.cpan.org/Ticket/Display.html?id=1483 >
>
> What happens is really simple. Test number 70 attempts to compress the sh binary, presumably because it is a safe bet that it exists. Only, under cygwin it isn't because although the program can be run as /usr/bin/perl, the filename is /usr/bin/perl.exe.
>
> Test 36 does the same with the perl binary, but wisely skips the test if it not found. Perhaps test 70 should do the same.
Are you sure this is exactly what's happening?
The whole lot is wrapped inside a -s $Config{'sh'} test:
if (-s $Config{'sh'}) {
open FOO, "<", $Config{'sh'} or die $!;
binmode FOO;
undef $/;
my $sh = <FOO>;
die "Can't slurp $Config{'sh'}: $!" unless defined $sh;
die sprintf ("Slurped %d, but disk file $Config{'sh'} is %d bytes",
length $sh, -s $Config{'sh'})
unless length $sh == -s $Config{'sh'};
close FOO or die "Close failed: $!";
if (open GZ, ">:gzip", "foo") {
print "ok 70\n";
} else {
print "not ok 70\n";
}
so it *ought* to be skipped if the file $Config{'sh'} has zero size, or
can't be found.
What I guess is happening is that the test is being caught out by a cygwin
"feature" whereby if the stat call for file "foo" fails, then it silently
also tries "foo.exe" and returns data for that. So I can get the size of
"sh.exe" because there is no "sh", but the open on "sh" fails.
Show quoted text> A more advanced version would also try 'which sh' and 'which perl', but of course then one has to take care of not dying if which fails (and it does surprisingly often, in my experience even on some badly configured HPUX.
I don't think I want to do that. It's easier to skip.
Nicholas Clark
