13

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.

Jared
  • 483
  • 1
  • 5
  • 11
  • As the answers explain, the extension is not important. For scripts (including Perl), the important thing is the [shebang line](http://en.wikipedia.org/wiki/Shebang_%28Unix%29). –  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
  • Side note: I had problems in Windows with `.pl` extension. I used it for writing Prolog programs, but some software identified it as Perl scripts. – Mephy Jan 27 '15 at 21:48
  • @amon What editors use a shebang line for syntax highlighting? All the ones I have use file extensions. – GrandmasterB Jan 27 '15 at 21:58
  • 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](https://en.wikipedia.org/wiki/File_%28command%29) (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
  • @amon most of the time I'm on Windows, so its file extensions for me. – GrandmasterB Jan 27 '15 at 23:10
  • 3
    Somewhere in there I thought we noted that the _.pl_ extension was for *p*erl *l*ibraries, and somehow morphed into what people used for programs. – brian d foy Jan 28 '15 at 13:35
  • FWIW, in Windows, if you create a perl script without an extension and put it in a CPAN distribution, that script will be installed on your system as a .bat file so that you can still call it without an extension. – stevenl Jan 29 '15 at 08:40

5 Answers5

15

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.

Keith Thompson
  • 6,402
  • 2
  • 29
  • 35
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.

coteyr
  • 2,420
  • 1
  • 12
  • 14
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.

Berin Loritsch
  • 45,784
  • 7
  • 87
  • 160
  • 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: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html#tag_20_11_05 – 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 01 '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 02 '16 at 01:01
  • I think might have gone of top here, the point I was trying to make is. – Aaron Goshine Sep 02 '16 at 05:18
  • 1
    Was there supposed to be more to that comment? – Keith Thompson Sep 02 '16 at 05:30
  • I think we might have gone of topic here, the point I was trying to make is: naming your script files with there respective extensions are a much better approach than without. In the excerpt above one of author claim is that it's a better to go without. Your package manager is evil by the way, you will not be able to host multiple version of the same software __unless your package manager go on to do additional evil mapping, which after a few rounds of installing and uninstalling softwares version problem arises__ not all softwares that get published on web are perfect examples great – Aaron Goshine Sep 02 '16 at 05:34
  • I disagree with almost every point you've made. – Keith Thompson Sep 02 '16 at 05:37
  • "not all softwares that get published on the web are perfect examples great – Aaron Goshine Sep 02 '16 at 05:39