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).

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 ;-)

But see the debugging section of CGI's documentation. A CGI environment can be faked.

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]

/usr/bin/perl -w $yourScript
[download]

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]

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.

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.

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?

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 ?

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.

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.

Please look on it here. It tells the difference between .cgi and .pl