On Wednesday, Oct 29, 2003, at 09:23 US/Pacific, Rick Triplett wrote:
Inserting print statements to print out the variables for examination, I found that $image_path was
/big/dom/xreason/www/images/tour.jpeg (document_root on my server is /big/dom/xreason/www )
I think this is the correct path.
I have both tour.jpeg and tour.png assigned permissions of 644 and stored in the file
www.reason.net/images/
so the 404 should not have been caused by a missing type of file.
Here is a way you MIGHT want to attack the problem.
I wrote a script:
my ( $image_type , $basename, $image_path ) = ("jpeg", "bob",
' ./Images/layers_and_levels.jpg');die "not -B :$image_path:\n" unless ( -B $image_path );
open(IMAGE, $image_path) or die "unable to open $image_path :$!";
my $buffer;
print "Content-type: image/$image_type\n\n";
binmode STDOUT;
my $count = 0;
while ( read( IMAGE, $buffer, 16_384 ) ) {
print " reached " . $count++ . " buffers \n";
#$buffer;
}and yes, there is an ADDITIONAL SPACE in front of that "image_path" - and it of course "dies" with the expected
not -B : ./Images/layers_and_levels.jpg:
and we have that "space" there before the $image_path element.
by including the line
$image_path =~ s/^\s*//;
the " " is taken out, and the '-B' passes. and we move along through the Open Working...
Unfortunately, the open() works with the the preceeding space, which suggests that the actual IMAGE file you are looking for is NOT on the server where you think it is.
eg, if I change that $image_path to point at a non-existent file we notice:
[jeeves: 9:] perl junk.plx
not -B :./Images/junk_not_here.jpg:
[jeeves: 10:] perl junk.plx
unable to open ./Images/junk_not_here.jpg :No such file or directory at junk.plx line 12.
[jeeves: 11:]
the former being the '-B' failure, the later being the die on the open...
which are the two features you noted.
HTH.
ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
