I'm not sure why Super Search didn't pan out for you. I searched for nodes containing the words "cgi upload save file." The second hit revealed a conversation discussing this very topic and providing relevant code.
I'd stay away from the first hit, though. It appears to advocate "the hard way" and there are several risks associated with that approach.
It might be worth your time to experiment with Super Search. It's a terribly useful resource and nothing to be afraid of.
--f
| [reply] |
pokemonk, when you say it didn't work, what happened, nothing at all? Because the CGI upload can go wrong in several places, so tracing if anything was transferred to the server is important.
As usual, make sure of this:
1. Make sure you are sending the ENCTYPE as "multipart/form-data" in your form
2. Make sure you are using CGI.pm correctly to receive it.
3. You didn't mention the platform of the server and the client, because it's not unreasonable to check if it works differently with IE vs. Netscape, and what version you are using. The cgi.pm docs say that inconsistencies arise with different combinations of platform/webserver/browser.
To help you trace what is going on, remember that CGI.pm works by uploading the file to a temporary directory specified in the CGI module, depending on the server's platform. And then you transfer it to your desired location in your code. So if you can determine if the temp file is being created, then that would greatly help in your debugging.
Addition: (After reading your reply below): You say you are using windows - what webserver are you using? Since you are eventually going to use this on Unix, I would suggest testing your script now on Unix. The upload problem you have may not be in your code, but in the relationship between win/webserver/browser. This is explicitly stated by the author of cgi.pm. PerlMonks users have posted problems with upload on windows servers, and I have had personal experience with the inability to upload on pre-OS X Mac webservers. Try it on your Unix machine and it may work with no problem.
| [reply] |
well sorry about that, right now i'm testing it in a windows platform, but i need it for unix, and for windows, and i'm using IE but it needs to work with most of the browsers.
the script creates a file, but it has no content, it's 0 bytes long. well i hope this looks better, if it doesn't please tell me.
my question is, why isn't this code working? and how can i fix it | [reply] |
You can't or its very hard to debug cgi w/o access to
the webserver's error log, so when you say "it didn't work"
you should be sure (and say) there's nothing in there.
Sprinkling a bunch of 'print STDERR' lines in the code (in
my favorite format, my $debug = 30;):
for ($loop=1; $loop <= $form{'files'}; $loop++){
if ($form{"img$loop"}){
print STDERR "in if: form var img${loop} is $form{img${loop}}\n"
if $debug > 15;
...
print STDERR "done mussing: form1 img$loop is $form1{img${loop}}\n"
if $debug > 10;
print STDERR "opening: form filename is $form{filename}\n"
if $debug > 20;
open(FILE, ">$form{'filename'}/$form1{\"img$loop\"}")
or die "can't open ", "$form{filename}/$form1{img${loop}}", ": $!";
while ($bytesread=read($file,$buffer,1024)) {
print STDERR "while: read $bytesread\n"
if $debug > 20;
You also seem to be unsure of the hash syntax; you
don't need single quotes for constants: e.g.
$hash{'this'} eq $hash{this};
and, if you're mixing a var in a string ("img$loop")
a good idea is to use the curly brackets to be sure it gets
handled (and to make it apparent to the humans; "img${loop}"
So:
$hash{"img$loop"} eq $hash{"img${loop}"}
but clearer/safer/cleaner is:my $this_loop = "img${loop}";
$hash{$this_loop} = ...
Doesn't cost you anything, code is more
readable and its easier to use/debug, just print
$this_loop or:my $img_file = "$form{filename}/$form1{$this_loop}";
open(FILE, ">$img_file") or die "can't open $img_file: $!";
Do this, look through the error log and then you can confidently
say 'its not working' ... probably, though, you'll see
something useful in there. Oh, if its a busy server,
prefix all the print STDERR msgs w/ "my_cgi: ..." so
they'll stand out in the log. And when it works, my $debug = 0
makes them all go away.
Update:Are you using (and if no, why not!? ;-)
cgi.pm? It does the upload for you (search on cgi upload sysread)
if you're using the upload stuff, so sysread won't find
anything to ... well read. 'course, that means all that
debugging would be for naught, but still its good practice.
Sort of that "set a monk on fire" idea (hmm, bad connotations
there, sorry).
a | [reply]
[d/l]
[select] |
