Alice, If you are already set 755 on the CGI, it looks like it might be a webserver configuration issue. If you are using Apache (I'm assuming you are) you might want to take a look at http://httpd.apache.org/docs/2.0/howto/cgi.html#configuringapachetopermitcgi for some hints on how to make sure that the server configuration is proper for using CGI scripts. Regards Jason On Thu, Jun 26, 2008 at 8:50 AM, Wei, Alice J. <ajwei@xxxxxxxxxxx> wrote: > Hi, Todd: > > It looks like I have some other errors in my Perl code, and I got it > fixed, switched the permission to 755, and made attempts to call it using > cURL through my working PHP script. > > Here is the code: > > // create a new cURL resource > $ch = curl_init(); > > // set URL and other appropriate options > curl_setopt($ch, CURLOPT_URL, "http://192.168.10.63/total.cgi"); > curl_setopt($ch, CURLOPT_HEADER, false); > > // grab URL and pass it to the browser > curl_exec($ch); > > // close cURL resource, and free up system resources > curl_close($ch); > > This time, I do not get the "script" output from the script in total.cgi, > but I got > > Forbidden > You don't have permission to access /total.cgi on this server. > > I have switched the permission to both scripts at both servers. Is there > something wrong I have done here? > > Thanks again for your help. > > Alice > ====================================================== > Alice Wei > MIS 2009 > School of Library and Information Science > Indiana University Bloomington > ajwei@xxxxxxxxxxx > ________________________________________ > From: Boyd, Todd M. [tmboyd1@xxxxxxxx] > Sent: Wednesday, June 25, 2008 5:07 PM > To: Wei, Alice J.; php-general@xxxxxxxxxxxxx > Subject: RE: Re: exec() Error > > > -----Original Message----- > > From: Wei, Alice J. [mailto:ajwei@xxxxxxxxxxx] > > Sent: Wednesday, June 25, 2008 3:31 PM > > To: Boyd, Todd M.; Per Jessen; php-general@xxxxxxxxxxxxx > > Subject: RE: Re: exec() Error > > ---8<--- snip > > > > Well, "http://www.mysite.com/calculate.php" is not an executable. > > Try > > > this instead: > > > > > > exec("php <path>/calculate.php"); > > > > I still don't think this is how exec() should be used when executing > > remote PHP scripts via HTTP, since the web server is not going to give > > you the underlying code simply because you're calling the URL from PHP > > and not your web browser. User-Agent tags do not a secure connection > > make. > > > > Perhaps doing a wget and directing it to /dev/null (if you're on *nix) > > would be appropriate to invoke a remote script and pass it parameters. > > Hell, even wget to standard output if you want, and use that as your > > "result code." It's basically doing what cURL does, but outside of the > > PHP script itself. > > > > Anyway, I digress. My point is that exec("php > > http://mysite.com/script.php") will fail, since it will be reading the > > remote script's OUTPUT, and not the remote script's SOURCE CODE. > > > > I dont' know how come his code works either. I figured that exec() > > is not going to get me anywhere when I have it stored remotely. > > I am now using cURL instead of using exec(), since it is doing a > lot > > closer to what I initiated. I am not sure if I should have a new > thread > > for this, but I found that things start to get a little weird when I > > tried to do cURL with Perl files inside. The PHP only brings me back > > Perl code and not the processed content. Is this something I should > not > > be doing with cURL? It seems to do quite a bit of powerful processing > > when I wrote everything in PHP and have it stored remotely. > > Alice, > > If it's returning the code instead of the processed content, then it > means that the webserver which houses the Perl script is not > executing/parsing it. You should check with the administrator of the > remote webserver to see if they have a Perl module installed, and if it > is configured properly for your web app. > > HTH, > > > Todd Boyd > Web Programmer > > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >