Any errors in the paraphrasing are my own. Refer to to the footnote at the bottom of page 7 in Learning Perl Objects, References & Modules.

Historically .pl stood for Perl Library. This was "back in the day" before modules were introduced. Nowadays you see fewer and fewer Perl Libraries in use as people migrate to proper modules. But libraries still are put to good practical use, so the .pl standard continues to exist.

.pm stands for Perl Module. This is an etched in stone convention that exists cross platform. The use statement expects that if you (for example) use Data::Dumper Perl should look for Dumper.pm in the Data directory in one of several possible places where modules typically reside.

Because some operating systems don't have an 'executable' file attribute, and don't look for shebang lines (the #!/path/to/perl line; these are always examine d for switches regardless of OS, but not necessarily for path to Perl and association) it has become somewhat of a convention to use .pl as an extension on Perl scripts that can be associated with the Perl interpreter (perl.exe, on these operating systems). For example, in the Windows registry, if one associates .pl files with perl.exe it will be possible to double-click on a .pl file and have it invoke perl.exe, much like you could click on a .doc file and have it invoke MSWord. It is an unfortunate requirement and convention, as it makes it difficult to differentiate between a Perl script and an old Perl Library.

The .cgi convention is not set in stone. It is dependant on your webserver configuration, and could be something different entirely or not even required. It's not strictly a Perl convention, as scripts written in other scripting languages could also use the .cgi extension to alert the webserver that it's a CGI script. And like I said, there are some webserver configurations where .cgi isn't even needed.

This is discussed in greater detail in the platform specific POD area of Perl's documentation and to some degree in perlrun.

You don't need to associate them as in UNIX/Linux the shebangs line takes care of it.

If you put #!/usr/bin/perl -w or whatever is approripate for your system based on where Perl is installed as the first line in your script, the shell will automatically execute the file for you when invoked from the command line.

Agreed, extensions are useful for searching and it is totally a personal preference and so nothing is enforced when it comes to Perl.

If you are looking for perl files and you did not have an extension, you can look for things "inside" the code while searching for all files. In UNIX you do it with the find | xargs grep commands. In Window$ you can bring the find utility and use the containing text box to search.

If you have been use my in your code then searching for my $ might help. Watch out when you do that in unix as $ should be escaped in std grep.

NOTE: Searching all the files for text will take too long! (depends on where and how many files you search)

-SK

I've also seen the extension '*.perl'. This appears to be used by some to indicate a text file somehow related to a script or module.