Re: CGI::Upload - CGI class for handling browser file uploads

[$code or die]

Looks really good. I really like the interface.

I'm curious though, CGI->upload() returns a filehandle, so does CGI->param() for that matter. I am wondering why in _handle_file() you read from this filehandle and write to a new tempfile so you can provide your own filehandle. Wouldn't it be easier to use the filehandle the CGI.pm provides?

One more thing, if you do need the new filhandle do you need to binmode() it for compatability?

___ Simon Flack ($code or die)
$,=reverse'"ro_';s,$,\$,;s,$,lc ref sub{},e;$,
=~y'_"' ';eval"die";print $_,lc substr$@,0,3;

[rob_au]

I'm curious though, CGI->upload() returns a filehandle, so does CGI->param() for that matter. I am wondering why in _handle_file() you read from this filehandle and write to a new tempfile so you can provide your own filehandle. Wouldn't it be easier to use the filehandle the CGI.pm provides?

I have actually considered this but haven't had a chance to read through the CGI.pm in detail to see exactly how it handles its temporary files. Much of this module code has evolved from subroutines that I have used in some CGI scripts in the past.

If anything, you might view the method I have taken as the defensive approach in the absence of any better informed opinion :-) This can also be seen in my resetting of the file pointer for the temporary file after calling the checktype_filehandle function from File::MMagic - While this resetting of the file pointer is in all likelihood unnecessary, I have included it for the sake of a "defensive" approach to this code.

As for the binmode on the newly-created file handle, this is a very good point - Again, I will look into this and the handling of temporary files by CGI.pm and revise this code accordingly.

Thanks again for you comments $code or die++

 

Update - I've had a look at the implementation of temporary files within CGI.pm and at this stage, I believe I will remain with the implementation I have in the code above - This is in part because of the robustness of the POSIX-based new_tmpfile method exported from IO::File which I am quite comfortable with from a "paranoia" perspective :-)

 

perl -e 's&&[e-mail]&&&split/[@.]/&&s&.com.&_&&&print'