10

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.

  • As the answers explain, the extension is not important. For scripts (including Perl), the important thing is the shebang line. – user22815 Jan 27 '15 at 19:47
  • 1
    No sir, don't agree. Without a file extension how do IDE's and programmers' editors decide on syntax highlighting? – GrandmasterB Jan 27 '15 at 20:56
  • 3
    @GrandmasterB by looking at the shebang line, or by reading modelines. I would never use a .pl extension for programs I'd want to distribute (that information is noise, not signal), but it's a useful reminder for local scripts. Anyway, this discussion is irrelevant for >90% of Perl code since it's either in a module (.pm extension required) or a test (.t extension customary). – amon Jan 27 '15 at 21:47
  • 1
    @GrandmasterB I develop on Linux, and both Vim and Kate correctly identify a file starting with the line #!/usr/bin/env perl as a Perl script if the file has no conflicting extension (such as .cpp). The file program (used to deduce a MIME type for a given input) correctly deduces text/x-perl regardless of extension. – amon Jan 27 '15 at 22:06
  • 3
    Somewhere in there I thought we noted that the .pl extension was for perl libraries, and somehow morphed into what people used for programs. – brian d foy Jan 28 '15 at 13:35
12

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.

1

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.

1

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.

0

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.

  • C compilers commonly treat their input files differently depending on the extension. For example, gcc treats . as C source code, .cpp, .cc, .C as C++ source code, .o as an object file to be passed on to the linker, and so on. You can override that with a command-line option, but I've used it so rarely that I don't remember what it is. The .c extension for C source files is important. The .pl extension for executable Perl scripts is not (at least on UNIX-like systems). – Keith Thompson Jan 27 '15 at 20:38
  • 1
    @KeithThompson: in fact, on a SUS-compliant Unix system, those file extensions are even part of the specification for the c99 command: pubs.opengroup.org/onlinepubs/9699919799/utilities/… – Jörg W Mittag Jan 27 '15 at 22:07
-4

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.

  • The statement about text editors might be valid -- but both emacs and vim are able to detect a Perl script without a special extension. Your claim about "best practice" would be more convincing with some support. I install Perl scripts on my (Linux) systems without extensions all the time, and it's never caused a problem. – Keith Thompson Aug 29 '16 at 22:09
  • Yeah, of course your script will run if it has the hash bang (#!) in line, You mention that you work on linux which is great.. the next time you install an application with a package manager pay close attention to how it also creates a symlink to you bin directory in stead of just writing the file directly into you bin directory.. every wonder why. – Aaron Goshine Sep 1 '16 at 21:15
  • Perhaps that depends on the package manager? On my Ubuntu 14.04 system, I have 325 Perl scripts installed directly under /usr/bin, not as symlinks; they were all installed by the system's package manager. The package manager has its own database that keeps track of the locations of all the files for each package. (For software that I build from source, I do use symlinks.) But I'm not sure what that has to do with whether Perl scripts should have a .pl extension. – Keith Thompson Sep 2 '16 at 1:01
  • I think might have gone of top here, the point I was trying to make is. – Aaron Goshine Sep 2 '16 at 5:18
  • 1
    Was there supposed to be more to that comment? – Keith Thompson Sep 2 '16 at 5:30

protected by gnat Nov 3 '16 at 18:26

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.