Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

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

by bjelli (Pilgrim)
on Apr 05, 2001 at 19:27 UTC ( #70133=note: print w/ replies, xml ) Need Help??


in reply to Bug in 'strict'??

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


Comment on Re: Bug in 'strict'? - CGI::SL, upload, CGI::Carp and stuff
Select or Download Code
Re: Re: Bug in 'strict'? - CGI::SL, upload, CGI::Carp and stuff
by dmmiller2k (Chaplain) on Apr 06, 2001 at 00:15 UTC

    > 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)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://70133]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (5)
As of 2014-12-27 12:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (177 votes), past polls