Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re: Use of .pl versus .plx file extensions

by hardburn (Abbot)
on Mar 15, 2004 at 15:38 UTC ( [id://336723]=note: print w/replies, xml ) Need Help??

in reply to Use of .pl versus .plx file extensions

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

Replies are listed 'Best First'.
Re: Re: Use of .pl versus .plx file extensions
by hding (Chaplain) on Mar 16, 2004 at 13:28 UTC
    As Perl stole .pl from Prolog before it. :-)
Re: Re: Use of .pl versus .plx file extensions
by tbone1 (Monsignor) on Mar 17, 2004 at 13:32 UTC
    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

Re: Re: Use of .pl versus .plx file extensions
by submersible_toaster (Chaplain) on Mar 17, 2004 at 12:58 UTC

    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.

Log In?

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

How do I use this?Last hourOther CB clients
Other Users?
Others studying the Monastery: (2)
As of 2024-07-19 21:10 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.