perl CGI

manish.rathi has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: perl CGI by targetsmart (Curate) on Mar 01, 2009 at 07:09 UTC
How does this CGI get invoked ? It would be invoked/executed by your webserver(apache), upon receiving requests from web client programs will perl interpreter be able to understand .cgi extension ? yes it can a good tutorial is here http://perltraining.com.au/courses/webdev.html, I suggest you to read it, before doing any big time activity on CGI Vivek -- In accordance with the prarabdha of each, the One whose function it is to ordain makes each to act. What will not happen will never happen, whatever effort one may put forth. And what will happen will not fail to happen, however much one may seek to prevent it. This is certain. The part of wisdom therefore is to stay quiet.	[reply]
Re: perl CGI by igelkott (Priest) on Mar 01, 2009 at 06:37 UTC
This is purely a webserver issue. Basically, you place the script into the appropriate folder (eg, cgi-bin), make it executable (if unix-like system), and make a link to it on a webpage. Consult your webserver's documentation for details (eg, apache).	[reply] [d/l]
Re: perl CGI by pobocks (Chaplain) on Mar 01, 2009 at 05:51 UTC
Perl doesn't actually give much of a hoot about file extensions. You could name your file gila.monster, and perl would run it just fine ;-) `for(split(" ","tsuJ rehtonA lreP rekcaH")){print reverse . " "}print "\b.\n";`	[reply] [d/l]
Re: perl CGI by ikegami (Patriarch) on Mar 01, 2009 at 06:39 UTC
CGI is a communication protocol using the environment variables, STDIN and STDOUT as communication channels. Perl knows nothing of CGI. While `perl file.cgi` (or any other extension) will execute, Perl won't populate the environment or STDIN appropriately. But see the debugging section of CGI's documentation. A CGI environment can be faked.	[reply] [d/l]
Re: perl CGI by talexb (Chancellor) on Mar 01, 2009 at 17:50 UTC
CGI written using perl is saved with .cgi extension. It can be -- but it doesn't have to be. Apache can be configured to run scripts in a certain directory as Common Gateway Interface scripts, which means Apache runs the scripts and sends the result back to the source of the original request. Typically, this means that Linux/Unix looks at the first line in the file, known as the hash-bang line, and uses that to actually run the script. In our case, it's going to be something like `#!/usr/bin/perl -w . .` [download] .. or even with the options `Tw` to turn tainting on. That means Linux/Unix will run the command `/usr/bin/perl -w $yourScript` [download] and send the output back to the source of the original request. How does this CGI get invoked ? That's part of the Apache configuration -- basically it means, "If the script is in this directory and it's executable, run it (with the parameters that make up the rest of the URL) and send the output back to the source of the request. The Apache configuration file will have something like `<Location /cgi-bin > SetHandler cgi-script Options +ExecCGI </Location>` [download] to configure Apache so that when it gets called with something like `http://www.yournamehere.com/cgi-bin/foo.cgi` it knows to treat `foo.cgi` as an executable script, and return the output of the script's run, rather than the script itself (which is what happens for static files). When we want to execute perl file, we just write "perl filename.pl" and that file is executed. In case of cgi, if it is executed as "perl filename.cgi", will perl interpreter be able to understand .cgi extension ? When you run a Perl script using the `perl $scriptName`, Perl doesn't care what the file extension is. It can be `pl`, `perl`, `foobarbaz` or have no extension at all. File extensions are important for the Windows operating systems, but Linux/Unix don't really rely on that; instead it relies on a combination of the hash-bang line and magic numbers to determine what a file type is. Apache is actually a pretty simple application. It just handles requests the come from browsers (or anything, really) over the HTTP protocol, and responds with an HTTP response. The request is something like a GET or a POST, and the response is a chunk of status information (perhaps a 200 if things went well, a 302 if the resource moved, a 404 if the thing wasn't found, or a 500 if there was a server error), optionally followed by some data. The data canjust be the contents of a file, or it can be the output of a script. And either of those can contain links to additional bits like graphics, style sheets, Javascript files and so forth. I used to think these things were magic too, but it's actually a fairly simple setup. I recommend you read lots about the subject, de-mystify it and then it will be a lot clearer for you. Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds	[reply] [d/l] [select]
Re: perl CGI by ruzam (Curate) on Mar 01, 2009 at 06:39 UTC
The webserver will be configured to recognize .cgi files as executable scripts and execute them rather than dish out the code source like a regular page. Or the .cgi files could exist in a directory (again configured by the webserver) to treat all files contained as executables.	[reply]
Re: perl CGI by dsheroh (Monsignor) on Mar 01, 2009 at 14:42 UTC
The web server has no idea that the CGI program is in Perl - CGI is just an interface specification and can be used to execute programs written in Perl, C, bash, or any other language. When the server executes a CGI program, it basically¹ just does the same thing as if you had typed `filename.cgi` on the command line. In the case of Perl programs on unix-like environments, the first line of the file will be something like `#!/usr/bin/perl` which tells the operating system to run the code through the Perl interpreter without the caller (i.e., the web server) needing to know that it's dealing with a Perl program. ¹ The web server also sets up various things in the environment, so that the CGI program is able to get information about the HTTP request that invoked it, but that's beside the point.	[reply] [d/l] [select]
Re^2: perl CGI by Marshall (Canon) on Mar 01, 2009 at 17:45 UTC
This is correct. The #!/usr/bin/perl acts like a special kind of a comment for a Unix program when that file has X permission. Also, Unix doesn't use file extensions to decide what kind of file it is looking at....it looks at the first part of the file to figure this out. If you say test whether some file is binary or not, Unix will look inside the file (and at more than just the first line...to decide binary or not) In a Windows environment this first line is NOT meaningless! If you have as first line: "#!/usr/bin/perl -w", Windows won't pay attention to the path /usr/bin/perl, but it WILL pay attention to the "-w", which means enable run time warnings. In Windows, you can associate .pl,.pm,.plx or whatever you want with Perl execution. The problems that I've found with Windows shell is that sometimes, you have to explicitly say: perl somefile.pl <infile >outfile to get the shell to do re-direction in the right way. You can just type "somefile" for normal execution of somefile.pl if you don't have shell input/output. I haven't figured out why this quirk exists in Windows, but I'm sure that it does. Perhaps somebody out there knows the "guts" of this?	[reply]
Re^2: perl CGI by manish.rathi (Acolyte) on Mar 03, 2009 at 00:16 UTC
Thanks for reply. Unix/linux environment looks at the shebang line to determine which interpreter to look for. I am working on windows and in windows, file extension suggests what interpreter to use. How will .CGI extension invoke perl interpreter ? If different executable cgi files are created using different languages eg java, php and perl, and all files reside in the same directory. In case of java file, it can be recognized with .class extension and jre will be used when this java file is invoked. But in perl and php , if both files have .cgi extension, how does the server understand which interpreter to use if both files have .cgi extension ?	[reply]
Re^3: perl CGI by Marshall (Canon) on Mar 03, 2009 at 16:59 UTC
This gets into some web server configuration specific stuff. You don't have to use .cgi for the extension. .pl is ok too. You can see this even without a server. Make a short .pl cgi script that just displays a page and you can navigate your browser to that file and it should run and display the result in browser provided that you have .pl associated with the Perl interpreter. This association only works for you as a user. So assuming you are running IIS on Windows platform, you also need to teach the server that .pl means a perl script. Use Regedit32, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ScriptMap, choose add value from tool bar. In the field labeled Value Name, type in .pl and use data type REG_SZ. When the String Editor dialog box shows up, type in C:\Perl\bin\perl.exe %s %s and hit OK. Now IIS should also understand what to do when it sees .pl. Of course adjust path name to perl.exe if you've installed it a different place.	[reply]
Re: perl CGI by sundialsvc4 (Abbot) on Mar 01, 2009 at 21:42 UTC
A review of various Apache directives should make this clear. Anytime Apache receives a URL, it will either deliver a file to you verbatim, or it will run something and deliver its output. Directives tell it which one to do. There are many variations, on this one simple idea.
Re: perl CGI by nagalenoj (Friar) on Mar 02, 2009 at 04:04 UTC
As the monks said, CGI is for web development. it has a set of configurations to be set in the web server. CGI cannot be placed in any directories. The configurations are given in the following url, Apache configuration for CGI If you wish to read about perl CGI, this will help you.	[reply]
Re: perl CGI by irah (Pilgrim) on Mar 02, 2009 at 06:10 UTC
Please look on it here. It tells the difference between .cgi and .pl	[reply]


The stupid question is the question not asked
	PerlMonks