Should Perl scripts really have no extension?

Question

I just began reading O'Reilly's Learning Perl, 6th Edition and was surprised when I came across this excerpt.

#!/usr/bin/perl
print "Hello, world!\n";

Let’s imagine that you’ve typed that into your text editor. (Don’t worry yet about what the parts mean and how they work. You’ll see about those in a moment.) You can generally save that program under any name you wish. Perl doesn’t require any special kind of filename or extension, and it’s better not to use an extension at all.

Why is it better to have no extension? Imagine that you’ve written a program to calculate bowling scores and you’ve told all of your friends that it’s called bowling.plx. One day you decide to rewrite it in C. Do you still call it by the same name, implying that it’s still written in Perl? Or do you tell everyone that it has a new name? (And don’t call it bowling.c, please!) The answer is that it’s none of their business what language it’s written in, if they’re merely using it. So it should have simply been called bowling in the first place.

This is the only source I've seen with this view, everything else I've read has supported the .pl extension. I'm no Perl programmer yet, and I wanted to know what the community's view on this was before I got into a habit.

Answer 1

The advice in the book is perfectly valid -- at least for UNIX-like systems. The execution of the script is controlled by the #! line, not by the extension part of the file name. Using a special extension for Perl scripts exposes information that should not be important to anyone running the script.

Windows is a different matter. Windows does not support the #! mechanism; instead, the method used to open a file depends on the extension. For example, the Windows shell might be configured so that double-clicking on a .pl file (or executing it from a prompt) will pass it as an argument to the Perl interpreter. Installing a Perl system will probably set that up for you automatically.

For Perl scripts intended to be portable, the .pl suffix required by Windows might "leak" onto UNIX-like systems. It's probably best to have a system-specific installation method that chooses an appropriate name for the script as it's installed.

On UNIX-like systems, a .pl extension is mostly harmless, and if you find it useful as a reminder of what language is used by a particular script (perhaps you have a collection of .pl, .py, .sh, and .rb scripts), then you can do that. But there are drawbacks to that approach, as described in the book: if you reimplement a script in a different language, you'll have to change the name and update anything that calls it.

(Perl modules need to have a .pm extension so that Perl can find them. For example, this:

use Foo::Bar;

will cause the interpreter to search for a file named Bar.pm in a a directory named Foo under one of the directories listed in the @INC array. But .pm files aren't meant to be executed directly.)

This is the only source I've seen with this view, everything else I've read has supported the .pl extension.

I find that surprising. Most of the advice I've seen says not to use the .pl extension for executable scripts.

Answer 2

Doesn't matter

#!/usr/bin/perl

tells the system what program to use to run the code.

if you changed that to

#!/usr/bin/bash

or

#!/usr/bin/python

you would use a different interpreter.

Having the extension is totally optional, and the point that the user doesn't need to know the language is 100% correct in most cases.

running add 2 3 and getting back 5 is all i care about (as a user).

The only time I add an extension to scripts is if I need the end user (some times my self) to know the language for some reason.

example.sh or example.pl to show to different ways to accomplish the same task.

All that said though, it is more common to not have an extension, but it's all taste.

Answer 3

The excerpt indeed makes a perfectly valid advice.

I would also add, that for a smaller system it is quite trivial to go over and rename a few files and/or strings here and there in case of changing your mind about the implementation.

On the other hand, a modern trend in developing largish systems implies having the main executable file without any extension while all the modules it depends on to still have the language-specific extension.

In fact, Python requires this by design, and usually the main Python script (the one without extension in the name) is just a few lines bootstrapping the whole app.

Answer 4

All the book is telling you is that on Unix, the file extension is nothing more than a convention. In reality, many types of files fall in to this category. Ruby files use the same convention so they don't need the .rb extension. C compilers only need valid C code, so you can name them .watoozy if you wanted to.

While there is no technical restraint, there is the practical constraint of the principle of least surprise. Basically, it would be very surprising to see ruby code in a .pl file, so people don't generally do that.

The one exception to the rule

In some server applications, the start up script is in an extension-less file to make it easier to start up the application as a service. The file looks like just any other compiled command in that case. As long as you have Perl installed, it will behave that way as well.

Answer 5

The excerpt, from the "O'Reilly's Learning Perl, 6th Edition" book is garbage. Comparing C to perl is not equivalent, for starters C will be compile to a binary, that does not have an extension.

Perl will not be compile so some text editors will need the extension in order to identify the filetype.

As apart of best practice you should not hardcode full script filename with extension anywhere in your system, You should always use a symlink or an alias depends on your operating system.

In the future if you need to change the original file, you only need to change the symlink to point to your new location.