Re: perl CGI

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.

Comment on Re: perl CGI Select or Download Code

Replies are listed 'Best First'.
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]