On Fri, Feb 04, 2005 at 03:23:49PM +0100, Ing. Branislav Gerzo wrote: > Paul Archer [PA], on Friday, February 4, 2005 at 08:14 (-0600 (CST)) > thinks about: > > >> I think he means that he wants his perl to generate HTML containing PHP. > > PA> Understood. My point was more along the lines of: "What do you really want > PA> to do, and why don't you state that clearly, instead of making us > PA> mind-read?" > > ok, sorry then. We have website done with PHP, it did my brother. But > I'm more into perl, so I did some scripts. Website is about checking > IPs (if it is up, and so on), so I wrote script for that. Ok, now my > problem: > > user come to website, write in textbox some IPs, I want send this > input to my perl script (parse that text, takes IPs, do operation with them - > insert them to database, check them...), and send results via _PHP_ to > user.
I think you're misunderstanding. PHP and Perl are both server side technologies in this particular situation. They BOTH generate HTML which is your client side interface. Regardless which you use, the client is none-the-wiser, nor should it matter. The "user" doesn't know or care about PHP. As far as your browser is concerned .php is just another ".html" extension. Don't believe me? "View Source" on a perl generated and php generated page and show me where you see your code that generated that page. Let me take a second to explain what happens at high level: For PHP. You request "script.php" your webserver notices its configured to do "something" with files with the ".php" extension, there's a "handler" built into the web server that gets handed your request, which has a buncha text, that's it. The handler opens script.php on the local filesystem, parses and executes the code based on the request and gives the web server back an html document, which the web server than gives to you. This means, NONE of your php code is ever transmitted to the client. Its interpretted on the server somewhere in the webserver's request handling timeline. For Perl CGI, its a little different. The webserver gets a request for /cgi-bin/perl.cgi and goes "hrm, this is a script directory, meaning requests have to be for executable files!". The web server check for the execute bit on the script, and then executes that script redirecting the entire request header to the STDIN of the script. You know why you put this line: #!/usr/bin/perl on all your scripts? Because that's how the OS figures out which interpretter to use to execute the following code. Apache actually doesn't even know its executing perl. You can put binary files in the cgi-bin that don't use interpretters. You can compile some c program, put it in th cgi-bin and have it execute, granted unless you know what you're doing, that's not a good idea at all, but, you get the idea. So in closing. you're original request makes no sense whatsoever. If you want Perl to generate a PHP source file and then execute that, YOU can do that.. Its a little tricky and slow as you'll have to run it through the CGI model using the old school UNIX technique of piping by using a wrapper script. #!/bin/sh /usr/bin/perl /web/root/cgi-bin/thing.pl |/path/to/php > > Thanks to all for replies! > > -- > > ...m8s, cu l8r, Brano. > > ["Bother!" said Pooh, as Piglet sacrificed him to the dark gods.] > > > > -- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > <http://learn.perl.org/> <http://learn.perl.org/first-response> > > -- Brad Lhotsky <[EMAIL PROTECTED]> -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
