Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

for goBoating or anybody else who can help me with this...

Status
Not open for further replies.

jett

Technical User
Sep 13, 2000
22
0
0
US
Hi, goBoating. Your script for file uploading is working but I run into a problem. I would like to use the script as part of another script I'm working on but this script uses 'standard' CGI and not 'my CGI'. Sorry for the poor explanation, I don't know how the different sorts of Perl are called but I think you understand what I'm trying to say.

I did two things:

1. Use your script as a seperate script and call it with 'require'. It didn't work.

2. Re-wrote your script into 'standard' CGI which didn't work neither. The variable can't be read into the script which resulted in a fatal error because it couldn't open the destination file.

Are you or anybody else able to give an hint how I can solve this problem? Is it possible to switch to 'my CGI' within a script and switch back to 'standard' CGI?

this is a stripped version of how I changed the script:

#!/usr/bin/perl

read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;


$input{$name} = $value;
}

print "Content-type: text/html\n\n";

$fileID= $input{'fileID'};

print &quot;$fileID<BR>\n&quot;;
@pathName = split(/\\/,$fileID);

# if $fileID is not null, read file from remote machine and write locally.
$newFile = '/home/andasoft/images/';
$newFile .= pop(@pathName);

# open a handle to the file you will write
open(OPF,&quot;>$newFile&quot;) || &showError(&quot;Failed to open OPF, $!&quot;);

# while you read from the remote machine, write to the output file.
while ($bytesread=read($fileID,$buffer,1024)) { print OPF &quot;$buffer&quot;; }
close OPF;

sub showError
{
# a generic complaint generator
my @error = @_;
print &quot;<CENTER><font color=\&quot;\#ff4500\&quot;>Fatal ERROR - @error</font><BR>\n&quot;;
print &quot;Submission aborted - your data was not saved!!<BR>\n&quot;;
print &quot;Please use the BACK button to return to the previous page<BR>\n&quot;;
print &quot;and correct the error.<BR></CENTER>\n&quot;;
print $query->end_form,$query->end_html;
exit;
}


Jett,

[sig][/sig]
 
OK, we're getting a little stirred up here.......

You said above....
&quot;The variable can't be read into the script which resulted in a fatal error because it couldn't open the destination file.&quot;

I'm not clear which var 'can't be read into the script'. Do you mean that
you can't get $fileID = input{'fileID'}; to work? If that is the case then, you
may need to expand your treatment of the incoming info from the browser to
handle GET and POST data.....

if ($ENV{'REQUEST_METHOD'} eq &quot;POST&quot;)
{
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
}
else
{
$buffer = $ENV{'QUERY_STRING'};
}

If you are dying because you can't 'open the destination file', then that sounds like a permissions problem. Make sure the web daemon has the ability to write to the destination dir and file.

'hope this helps..... [sig]<p> <br><a href=mailto: > </a><br><a href= > </a><br> keep the rudder amid ship and beware the odd typo[/sig]
 
I use 'Post' so I don't think I use the wrong syntax to read the variable (the file variable) or are file field always sent as 'get' (I'm going to try this). I put a print command in the script to print $fileID which remained empty. That's why my guess is that the script can't open the destination file as basically there isn't a file to open or to write to.

When I put the print command in your original script it does print $fileID correctly and it saves the file in the right destination which means that permissions are set correctly!

Contrary to text fields the file field in the form somehow can't be read using 'normal' CGI?

Jett
[sig][/sig]
 
If you are not catching a value for $fileID, then the problem is very basic( sometimes those are the hardest to find). Catching an input from a web page is a very basic behavior for CGI code. While the syntax may look different whether you're using CGI.pm or not, the trick is still the same basic trick. Your browser is submitting some information and the CGI code is parsing it to get the name/value pairs. My suspicion is that there is something wrong with the way you have named the input in your HTML or something like that. Again, if you are not getting a value for $fileID, then the problem is basic and very early in the process flow. I would hack out all of the code following
$fileID = input{'fileID'};
and work on that until I got $fileID populated.

' gotta get home to dinner. I'll check back in the morning. Good Luck. [sig]<p> <br><a href=mailto: > </a><br><a href= > </a><br> keep the rudder amid ship and beware the odd typo[/sig]
 
Maybe getting a little closer.

As said in the documentation of Dreamweaver ENCTYPE=&quot;multipart/form-data&quot; should be added to the form tag when using file fileds which I did and works fine with CGI.pm.

After removing this part from the form tag $fileID gets populated and the file is written to the destination directory. However &quot;0&quot; bytes are stored so I'm afraid ENCTYPE=&quot;multipart/form-data&quot; is needed in the form tag?

Kinda stucked on this!?

Jett [sig][/sig]
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top