As with most topics in Perl, there is more than one way to do things. You will see some scripts ending in .pl and some ending in .cgi. What is the difference between the two?
There is no difference. They are both executable Perl script extensions. *.pl is enabled by default and most servers also enable *.cgi.
However, I urge you to pick a convention and stick with it. It will make things much easier for you over the years.
What do I mean by that?
When I am writing a script that will be used by a client, then I always end the executable in *.cgi. However, if I’m writing a script to test some code or perform a function I need as part of my work, I always use *.pl.
This let’s me know at a glance if the file is a production file or a utility file.
Define your own conventions for support files too.
It’s nearly impossible to write anything substantial without having to “require” other files. These can be *.pl or *.cgi files. However, as the theme of thos post is conventions, I’m going to urge you to define a few new “conventions” for yourself.
When I write a program, I create all of the supporting files that get “required” with an extension of *.lib. This way when I look at a file I know by it’s extension what it is:
- *.pl = Script I’m using myself to achieve a specific purpose.
- *.cgi = An executable script that is part of the final production package.
- *.lib = A file full of nifty Perl code that gets “required” by another file (you can use any text.unrecognized extension).
I take it a step further though…
Any file that contains code that is used by many other supporting files gets prefaced with “init_”.
To keep my sanity while working on multiple projects, I preface any procedure file with a tag that indicates the project.
In this example, I’m creating a project for the “Fish Monkey Reviewer Site,” a site dedicated to reviews of monkey fish.
My main script that the public access is called:
With this, I need to have a way for the site owner to login and update reviews he or she wants to include. Those procedures get saved in these files:
fm_user_login.lib fm_user_logout.lib fm_user_reviewslist.lib fm_user_reviewsadd.lib fm_user_reviewsedit.lib fm_user_reviewsdelete.lib
However, I also need some supporting functions:
init_password_generator.lib init_encryption.lib init_get_date.lib init_constants.lib
So now, looking at the full list, it’s very easy for me to know exactly what a file is by looking at the naming structure.
reviews.cgi fm_user_login.lib fm_user_logout.lib fm_user_reviewslist.lib fm_user_reviewsadd.lib fm_user_reviewsedit.lib fm_user_reviewsdelete.lib init_password_generator.lib init_encryption.lib init_get_date.lib init_constants.lib
In this small list of eleven files, it may not appear to be of much benefit. However, when you have a project with 50 or 60 files, then the value of having your own strict convention of nomenclature becomes apparent. I’ve written project that have a hundred or more supporting files (clarifies what is going on to put one feature in one file).
Only one question remains …
How many of you tried googling for “Monkey Fish”?
Yes, it’s a real thing.
Now go, code, be happy. 🤓