Re: Bug in 'strict'? - CGI::SL, upload, CGI::Carp and stuff

[bjelli]

I played around with your Code with Netscape on Windows 2000 as the client, Apache on Debian. I ran into different problems:

1) CGI::SL

My client supplies the Filename "C:\WINNT\Media\Chimes.wav", while CGI::SL is /. Your pattern-matching/substitution thing did not work out, localfile got set to the whole filename. I'd recommend To be safe, use the upload() function (new in version 2.47). When called with the name of an upload field, upload() returns a filehandle, or undef if the parameter is not a valid filehandle. $fh = $query->upload('uploaded_file'); while (<$fh>) { print; } This is the recommended idiom.

2) upload and strict refs

trying to read from $filehandle I got the error:

Can't use string ("C:\WINNT\Media\chimes.wav") as a symbol ref while "strict
refs"...

In the manpage for CGI I found:

However, there are problems with the dual nature of the upload fields. If you use strict, then Perl will complain when you try to use a string as a filehandle. You can get around this by placing the file reading code in a block containing the no strict pragma.

So a quick way to fix your code turned out to be

{
        no strict;
        while (my $bytesread = read($filename,$buffer,1024))
        {
           print FILE $buffer;
        }
}

But Beware! the CGI man page goes on to talk about security problems with this whole filename/filehandle-duality.

To be safe, use the upload() function (new in version 2.47). When called with the name of an upload field, upload() returns a filehandle, or undef if the parameter is not a valid filehandle.

$fh = $query->upload('uploaded_file');
            while (<$fh>) {
                  print;
            }

This is the recommended idiom.

Debugging-Output from CGI

When debugging CGI don't count on the fact that your script "didn't even get there" if you can't see a certain line of debugging output. In my experience webservers tend to chew off some of the output (just when you least expect it, see also Murphys Law :-). Look into the server logfiles, or use CGI::Carp qw(fatalsToBrowser);

That gives you all the error-messages right in the Browser.

--
Brigitte    'I never met a chocolate I didnt like'    Jellinek
http://www.horus.com/~bjelli/         http://perlwelt.horus.at

[dmmiller2k]

> or use CGI::Carp qw(fatalsToBrowser);

> That gives you all the error-messages right in the Browser

This too, is a misleading statement. If you have compile-time errors, these may or may not appear in the browser, depending upon whether the 'use CGI::Carp' has been evaluated before the compile-time error.

I've unfortunately had way too many situations where I was forced to look in the server error log (difficult, at best, if you're using a hosting company) anyway, even with use CGI::Carp qw(fatalsToBrowser);.

But then, this is a little off-topic, is it not?

(we now return you to your regularly-scheduled debate)