Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Use of .pl versus .plx file extensions

by bradcathey (Prior)
on Mar 15, 2004 at 14:59 UTC ( [id://336713]=perlmeditation: print w/replies, xml ) Need Help??

Fellow Monks,

Fundamental stuff here, but curious. I have always used a .pl extension when naming my perl programs. This seems to be the common extension, our own PM included. However I just read Randal L. Schwartz, in Perl Objects, Reference & Modules, suggesting that we use .plx for these, and reserve .pl for libraries, and, of course, .pm for modules. In fact, he even goes so far as to eliminate any extension if the server allows it.

Perldoc, Google and Super-Search shed little light on the topic, but I did read ".pl" for Unix and ".plx" for NT.

What is the prevailing thinking, or am I making a big deal over nothing?

"A little yeast leavens the whole dough."

Replies are listed 'Best First'.
Re: Use of .pl versus .plx file extensions
by rinceWind (Monsignor) on Mar 15, 2004 at 15:18 UTC
    A Unix box, doesn't care what file type is used for a perl script, as you are always required to put the filename in full (though you can get the shell to do some of the fingerwork for you with autocomplete). With other O/S, the picture is more muddy.

    Under Windows, you can associate .pl (or .plx) with the Perl executable, allowing clickable icons etc. but this is not recommended or needed. Normally, any standalone scripts you want to run as commands can be converted to .bat files with pl2bat.

    VMS requires a symbol (cf alias) to be set up for everything that is run as a command, hence this can (and does) include the instruction to run perl.

    In practice, there are many scripts distributed on CPAN which do not have the form *.pl:

    • t/*.t are the tests for a module
    • *.cgi are example CGI scripts
    • Commands are often distributed with no extension at all.

    I can understand and sympathise with Randall's reserving .pl for libraries. However, I can't think of the last time that I "require"d a .pl file in code I have been writing.

    Hope this helps

    I'm Not Just Another Perl Hacker

Re: Use of .pl versus .plx file extensions (neither)
by tye (Sage) on Mar 15, 2004 at 16:44 UTC

    Under source control, my scripts are called *.pl. The install procedure moves them into the proper 'bin' directory, removes the '.pl' from their name, adjusts the path to Perl in the #! line, and does "chmod +x". Under Win32, I use pl2bat in place of several of those previous steps.

    I never use " args" nor "perl script args" except for one-offs, because there are times when 'script' gets reimplemented in a different language and I don't want to have to find all the places that use 'script' and change them. For example, I might start with a *.cmd file (same as a *.bat file but I use *.cmd to distinguish them from Perl scripts that have been run through pl2bat) and later add features as part of reimplementing it in Perl.

    - tye        

Re: Use of .pl versus .plx file extensions
by DaWolf (Curate) on Mar 15, 2004 at 15:44 UTC
    Actually .plx is an extension to use ActivePerl and IIS with ISAPI.

    I've used a lot in a project involving ActivePerl on a NT box a couple of years ago.

    Althrough rincewind is a 101% right by stating that *nix systems don't really care about file extensions, my opinion is that it's always a nice thing to keep an extension in mind, so you can easyly recognize any kind of files that you have on your system.

    Of course this is a "75% of the time Windows user" opinion :)

    Best regards,

    my ($author_nickname, $author_email) = ("DaWolf","erabbott\") if ($author_name eq "Er Galvão Abbott");
Re: Use of .pl versus .plx file extensions
by hardburn (Abbot) on Mar 15, 2004 at 15:38 UTC

    I've noticed some media players (like Sonique) on Win32 tend to "steal" the .pl extention on installation for playlists by default.

    These days, you're better off ignoring the extention, except as a quick-and-dirty way to know what's in the file from an 'ls' or 'dir' listing. It's easy to fall into the trap of making extentions meaningful to programs (I'm guilty of this in Gopher::Server::TypeMapper), but try to find a better way to determine filetypes automatically.

    (I wish more operating systems would store the MIME type as meta-information on the file. Then we can finally be rid of this name-extention garbage.)

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

      As Perl stole .pl from Prolog before it. :-)
      Then there is also what you have to do at work. In a former job, I had to use the ".pl" extension because a higher-up saw it in a URL and asked what it stood for. "Perl script", I said, being the only Perl programmer there, and lo, another carefully-thought-out standard was rammed down everyone's throat by a PHB who knew as much about logic and process as a mound of live bait.

      Personally, I like ending them in ".ksh" and watching people's faces when they see regular expressions for the first time. Evil, but in a good way.

      tbone1, YAPS (Yet Another Perl Schlub)
      And remember, if he succeeds, so what.
      - Chick McGee

      Store the MIME type ? It's a derivitive of the file's essence - keeping that information in sync is a nasty problem. Have you experienced HFS idea of storing meta-information?

      Sorry. I hate to be a miserable pedant, but I was agreeing with you right up to the last point. Damn and blast these file extentions, but let a file be a file , not several streams of info that stay relevant to each other until after the first :w!

      I can't believe it's not psellchecked
        let a file be a file , not several streams of info that stay relevant to each other until after the first :w!

        I have to disagree with you here. Certain useful metadata must be kept in sync with a file's contents. The length of the file, and the file's last modified date, for example. While you could argue that these are unneccessary, it's extremely difficult to live without them. Sure, you could have null-terminated files, but then you couldn't store binary data. (You could get around this by backslash-escaping non-terminating nulls, and then backslash-escaping every backslash, but I shudder to think of a filesystem that required any of that.). Sure, you don't *need* to know when a file was last modified, but then it's a lot harder to do incremental backups.

        With those two examples, the operating system deals with keeping the metadata in sync with the file. But what about a program? In UNIX, the hasbang line we all know and love acts as metadata, because it says what program should be used to run the file (I'm a UNIX newbie, so correct me if I'm wrong about this). Port a shell script to Perl, but leave a #!/bin/sh at the top, and it's not going to work correctly if you try to execute the file.

        So now that we've found an instance in which it is more convenient to store metadata about what program can understand a file, why not extend that to storing metadata about what kind of file it is? Suddenly, you can have the OS figure out what to do with the file when you open it (even more so if you store creator AND filetype metadata). Applications can figure out on their own which files they can open and process. Searching can be done for certain kinds of files.

        The benefits of all this kind of metadata far outweigh the costs of maintaining it. Besides, is it even that common to have one file whose type changes often?

        For more info, read John Siracusa's Metadata, The Mac, and You at ArsTechnica.

        Once it's Turing complete, everything else is just syntactic sugar.
Re: Use of .pl versus .plx file extensions
by Abigail-II (Bishop) on Mar 15, 2004 at 15:54 UTC
    am I making a big deal over nothing?
    Yes. Perl itself doesn't care, it only cares about .pmc? extentions. So, whether you use an extention at all for your program, and if you use an extention, which one to use, is a local decision. Your OS or your webserver might require an extention to have it run as a Perl program, but in that case, you have to configure your OS or your webserver to use what ever fancies you.

    Unix OSses don't care. While some OSses use an extention of the file name to determine what kind of file they are, Unix make use of magic bytes in the content of the file. Both "solutions" are annoying, prune to errors and are inferior to solutions that separate meta-information from the data.


      Oh no! Not the dreaded .pmc extension! Blot it out! Pretend it doesn't exist! Down with ByteLoader!
      Thanks, Abigail II. I guess I'm not only interested in what strikes me as useful, but possibly those that follow. I.e., will my choices help or hender the next programmer that has to deal with my code (you know, after I get run over by a bus)?

      "A little yeast leavens the whole dough."
        I'd say avoid the programmer who's either bothered by having a .pl or .plx extention, or for whom such an extention is really helpful.

        For a good programmer, it shouldn't matter.


Re: Use of .pl versus .plx file extensions
by flyingmoose (Priest) on Mar 15, 2004 at 21:30 UTC
    My bank has what is apparently a cgi directory using ".dll" files. I am praying they have a really funny sysadmin who has named their Perl scripts ".dll" as a joke, though I am not confident in their coolness. Be afraid. Be very afraid.

      Grab a copy of Mozilla and the LiveHTTPHeaders extension. Watch to see what the server you access announces itself as. Sites that use Windows will most likely display a header that looks like:

      Server: Microsoft-IIS/4.0

      Of course, there are many people who believe that Windows must be the best thing out there, otherwise why else would so many people use it? So they go, and they get a Windows box, and for speed they create CGI scripts based in C. I am waiting patiently for the day one of these servers gets hosed, it gets national publicity, and I get to point and laugh.

      Want to support the EFF and FSF by buying cool stuff? Click here.
        "Grab a copy of Mozilla and the LiveHTTPHeaders extension. Watch to see what the server you access announces itself as."

        Yuck, why all the hassle of installing and firing up Mozilla (+LiveHTTPHeaders) when LWP provides you with lwp-request (and HEAD)? Or if that's not installed on your box, what about telnet?

        $ lwp-request -m HEAD <url> $ HEAD <url> $ telnet <server> 80 Trying <>... Connected to <server> Escape character is '^]'. HEAD / HTTP/1.0
        "Of course, there are many people who believe that Windows must be the best thing out there, otherwise why else would so many people use it?"

        I'm fairly sure a lot of people know smoking is bad for their health, yet they still smoke a pack a day.


        All code is usually tested, but rarely trusted.
      I have always found sites that use .dll scary, as well.

      One that I have encountered quite often is allmusic. For having such great content, their HTML and javascript are incredibly ugly.
Re: Use of .pl versus .plx file extensions
by castaway (Parson) on Mar 16, 2004 at 11:00 UTC
    Just for your curiosity. I use '.perl' for my perl scripts, why abbreviate in this day and age? :) .pm is used for libraries and modules, no idea why one would have to differeniate between these.


Re: Use of .pl versus .plx file extensions
by demerphq (Chancellor) on Mar 23, 2004 at 10:28 UTC

    As another monk mentioned the .plx is an Activestate extension for PerlScript code that will be run off of an IIS web server (or rather more accurately an ISAPI enabled web server). Contrary to assertions made by some monks perl extensions do have meaning and the pervailing conventions shouldn't be ignored. For instance a .plx file shouldn't contain exec() as it isnt supported by the PerlScript engine. For CPAN authors using .perl (or other non .pl variants)instead of .pl is a bad idea as .pl scripts will get installed automatically in the perl/bin directory when doing a make install and their personal favorite wont. At least not without annoying modification of their (or maybe their, which in of itself shouldn't be renamed or the automated systems in or will break.

    Theres another, totally aesthetic reason for complying with convention. For OS's that support associating icons to extensions it means that all of the various types are visually differentiable. For instance on my system all of the different common extensions have an icon associated. .pl files have the old style ActiveState yellow pearl, .pm have a nice dark blue pearl, and .t files have a nice green one. So if I download your conventionally named files ill readily identify them and their type by icon, the oddball variants wont be so easily distinguished. So id say stick with the conventional names unless you have a really good justification for doing so.


      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi

Re: Use of .pl versus .plx file extensions
by Eyck (Priest) on Mar 17, 2004 at 09:35 UTC
    Randal is right. What's the use of extension in programs? Would you like to change all you scripts that use 'find' to use '' instead? Or '' or whatever 'Language of the week' uses?

    And if you're skilled mouse master then you don't care at all how the script is called.

      True, but the same can be said for extensions of graphics. Todays .jpg might be tomorrows .png. Yet, people often find it useful to give their graphics an extension. Given that, I don't find it surprising they want to give their Perl programs an extension.

      Usually, I don't give my Perl programs extensions - although sometimes, I do (mostly to trigger my editor to go into Perl mode).


        This shouldn't be necessary as long as you use shebang #!/usr/bin(whatever)/perl in your scripts. Both emacs and vim recognize files this way.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://336713]
Approved by BazB
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (2)
As of 2024-07-21 17:37 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.