FAQ
This question came up after the web frameworks night yesterday, many
people seem to think it's ugly.
Should we remove the .pl extension from scripts?


--
sebastian

Search Discussions

  • Christopher H. Laco at Nov 19, 2005 at 1:32 am

    Sebastian Riedel wrote:
    This question came up after the web frameworks night yesterday, many
    people seem to think it's ugly.
    Should we remove the .pl extension from scripts?


    --
    sebastian
    Here's what I said on #catalyst:

    [x] No

    #1. Many editors base their syntax highlighting and editing rules on
    file extensions on the file extension. Whether you should or shouldn't
    get editing those files is irrelevant.

    #2. Windows hates to run files without file extensions, They may or may
    not be an issue. Windows cones with catalyst.bat, which runs when you
    type C:> catalyst MyApp. IF the perl script were named the same thing,
    that may not work. Windows people would be forced to always doing perl
    catalyst.pl.

    #3. Unless there is some intention of these scripts changing to say
    bash, oy pything, or something else that could be specified in the
    shebang, there's not reason to make it an ambigous file name.

    - -=Chris
  • Jules Bean at Nov 19, 2005 at 8:52 am

    Christopher H. Laco wrote:
    #1. Many editors base their syntax highlighting and editing rules on
    file extensions on the file extension. Whether you should or shouldn't
    get editing those files is irrelevant.
    Fix your editor. Or use a better one. This is the 21st century you know.
    #2. Windows hates to run files without file extensions, They may or may
    not be an issue. Windows cones with catalyst.bat, which runs when you
    type C:> catalyst MyApp. IF the perl script were named the same thing,
    that may not work. Windows people would be forced to always doing perl
    catalyst.pl.
    No comment. I have no idea. If this is really a problem then that could
    be a valid reason.

    #3. Unless there is some intention of these scripts changing to say
    bash, oy pything, or something else that could be specified in the
    shebang, there's not reason to make it an ambigous file name.
    I find nothing 'ambiguous' about the name without the .pl.

    Jules
  • Christopher H. Laco at Nov 19, 2005 at 6:10 pm

    Jules Bean wrote:
    Christopher H. Laco wrote:
    #1. Many editors base their syntax highlighting and editing rules on
    file extensions on the file extension. Whether you should or shouldn't
    get editing those files is irrelevant.

    Fix your editor. Or use a better one. This is the 21st century you know.
    How about some more fact rather than a quip?
    I believe SciTE is a rather well known non broken editor in that
    reqpest. I would wager that the majority of all editors check the file
    extension as the very first check in mapping files to languages and
    language parsers.

    I would also argue that having an editor guess what my file is by it's
    contents is more prone to error than the file extension.

    #2. Windows hates to run files without file extensions, They may or may
    not be an issue. Windows cones with catalyst.bat, which runs when you
    type C:> catalyst MyApp. IF the perl script were named the same thing,
    that may not work. Windows people would be forced to always doing perl
    catalyst.pl.

    No comment. I have no idea. If this is really a problem then that could
    be a valid reason.

    #3. Unless there is some intention of these scripts changing to say
    bash, oy pything, or something else that could be specified in the
    shebang, there's not reason to make it an ambigous file name.

    I find nothing 'ambiguous' about the name without the .pl.
    How is that?

    Here's a file: /usr/local/myfile

    What is it? Yup, you can't tell without opening it first, or TRYING to
    run it. If it has no shebang of execute bit, you're screwed. Now you
    have to open it to figure out how to run it.

    - -=Chris
  • Jules Bean at Nov 19, 2005 at 6:45 pm

    Christopher H. Laco wrote:
    Fix your editor. Or use a better one. This is the 21st century you know.
    How about some more fact rather than a quip?
    My apologies. It was not intended to be a quip, just rather brief and to
    the point.
    I believe SciTE is a rather well known non broken editor in that
    reqpest. I would wager that the majority of all editors check the file
    extension as the very first check in mapping files to languages and
    language parsers.
    Well the important point is actually how the *operating system* will
    decides it's a perl file. Since my operating systems (that is, the ones
    I am familiar with using) do that by checking the shebang, so does my
    editor. Seems sensible to me. I have no idea how win32 does this. I
    daresay win32 can be configure to push all script files through an
    installed copy of bash, and bash like most shells will notice the
    shebang and exec() perl. I've never used SciTE (hadn't heard of it until
    today), I glanced at the web page, it looks pretty good so I'm rather
    surprised if it can't set modes based on the first line of the code, but
    maybe it can't.

    I find nothing 'ambiguous' about the name without the .pl.
    How is that?

    Here's a file: /usr/local/myfile

    What is it? Yup, you can't tell without opening it first, or TRYING to
    run it. If it has no shebang of execute bit, you're screwed. Now you
    have to open it to figure out how to run it.
    Personally, I run the 'file' utility, as in 'file /usr/local/myfile'.
    Sample output on a reasonable assortment of files I happen to have lying
    around:

    Microsoft Office Document
    ASCII English text
    TIFF image data, big-endian
    JPEG image data, EXIF standard, comment: "AppleMark"
    JPEG image data, EXIF standard 2.2
    JPEG image data, JFIF standard 1.01
    PDF document, version 1.5
    MS-DOS executable (EXE), OS/2 or MS Windows
    PostScript document text conforming at level 2.0
    TeX DVI file (TeX output 2004.12.01:1940\213)
    XML document text
    gzip compressed data, was "Archive.tar", from Unix
    perl script text executable
    Perl5 module source text
    HTML document text
    PNG image data, 171 x 244, 8-bit colormap, non-interlaced
    Mach-O executable ppc


    ...and so on.

    In fact most sensible file formats (including shebang executables, but
    also including PNG, JPEG, ELF executables, and so on) have information
    in the first few bytes which uniquely identify the file type. I would
    content that this is much more robust than depending on file extensions
    which anyone can change.

    Jules
  • Christopher H. Laco at Nov 19, 2005 at 6:51 pm

    Jules Bean wrote:
    Christopher H. Laco wrote:
    Fix your editor. Or use a better one. This is the 21st century you know.

    How about some more fact rather than a quip?

    My apologies. It was not intended to be a quip, just rather brief and to
    the point.
    No, don't apologise. I'm feeling prickish this morning. I need to chill
    and listen better. Such is my weakness. :-)

    - -=Chris
  • Johan Lindström at Nov 19, 2005 at 9:51 am

    At 01:38 2005-11-19, Christopher H. Laco wrote:
    #2. Windows hates to run files without file extensions, They may or may
    not be an issue. Windows cones with catalyst.bat, which runs when you
    type C:> catalyst MyApp. IF the perl script were named the same thing,
    that may not work. Windows people would be forced to always doing perl
    catalyst.pl.
    As a Windows user, I'll second that objection.

    Things that are marked up as scripts and installed in the system are
    converted to batch files by "nmake install" or "perl Build install". That's
    why it works to run "catalyst".

    But this isn't the case when it comes to the scripts in the script
    directory. They are run with "script\myapp_create.pl ..." and as such
    Windows needs the extension to figure out its Perl. These may be installed
    and converted to bat if I would install my app, but the batch files are not
    available during development.

    IIRC, the objection to .pl was a cosmetic one (and I agree on that). But
    let form follow function on this one please.


    /J
  • Jules Bean at Nov 19, 2005 at 8:50 am

    Sebastian Riedel wrote:
    This question came up after the web frameworks night yesterday, many
    people seem to think it's ugly.
    Should we remove the .pl extension from scripts?
    I thought that was a really bizarre point (someone made it on london.pm,
    I think). Personally I have no objection but I think it's really odd to
    worry about.

    Jules
  • Corey at Nov 19, 2005 at 11:34 am

    On Saturday November 19 2005 7:55 am, Jules Bean wrote:
    Sebastian Riedel wrote:
    Should we remove the .pl extension from scripts?
    Let's not focus/obsess on mere aesthetics. It's silly. Further, I for one
    prefer actual usefullness over arguable subjectivity - such as the opinion
    of .pl extension as being "ugly". I don't think they're ugly, I think they're
    beautiful. I love .pl extensions. They remind me that I'm using perl. But
    that's all moot.

    What's important is that editors often use extensions for functionality.
    Scripts often look for extentions to do stuff. Human beings often use
    extensions to avoid ambiguity at a glance.

    Those are the reasons why the .pl extentions should remain.
  • David Storrs at Nov 19, 2005 at 6:36 pm

    On Nov 19, 2005, at 5:34 AM, Corey wrote:
    On Saturday November 19 2005 7:55 am, Jules Bean wrote:
    Sebastian Riedel wrote:
    Should we remove the .pl extension from scripts?
    Let's not focus/obsess on mere aesthetics. It's silly. Further, I
    for one
    prefer actual usefullness over arguable subjectivity - such as the
    opinion
    of .pl extension as being "ugly". I don't think they're ugly, I
    think they're
    beautiful. I love .pl extensions. They remind me that I'm using
    perl. But
    that's all moot.

    What's important is that editors often use extensions for
    functionality.
    Scripts often look for extentions to do stuff. Human beings often use
    extensions to avoid ambiguity at a glance.

    Those are the reasons why the .pl extentions should remain.

    Agreed. And very well said.

    --Dks
  • Sascha Kiefer at Nov 19, 2005 at 12:09 pm
    Keep em.
    Windows needs em.


    --esskar
    -----Original Message-----
    From: catalyst-bounces@lists.rawmode.org
    On Behalf Of
    Sebastian Riedel
    Sent: Samstag, 19. November 2005 01:26
    To: The elegant MVC web framework
    Subject: [Catalyst] Remove .pl from scripts?


    This question came up after the web frameworks night yesterday, many
    people seem to think it's ugly.
    Should we remove the .pl extension from scripts?


    --
    sebastian


    _______________________________________________
    Catalyst mailing list
    Catalyst@lists.rawmode.org
    http://lists.rawmode.org/mailman/listinfo/catalyst
  • Robert Sedlacek at Nov 19, 2005 at 1:33 pm

    Sebastian Riedel said:

    This question came up after the web frameworks night yesterday, many
    people seem to think it's ugly.
    Should we remove the .pl extension from scripts?
    Due to some experiences with customers I came to the conclusion that I
    always want to supply the proper file extension. I don't think the
    information which interpreter runs certain scripts should be only
    discoverable by looking into the files themselves.

    That might have not been proper english. But I just woke up and am having
    my first coffee.
  • Kaare Rasmussen at Nov 19, 2005 at 2:28 pm
    Should we remove the .pl extension from scripts?
    Yes.
  • Sebastian Riedel at Nov 19, 2005 at 6:18 pm

    Am 19.11.2005 um 18:16 schrieb Christopher H. Laco:
    How about some more fact rather than a quip?
    I believe SciTE is a rather well known non broken editor in that
    reqpest. I would wager that the majority of all editors check the file
    extension as the very first check in mapping files to languages and
    language parsers.

    I would also argue that having an editor guess what my file is by it's
    contents is more prone to error than the file extension.
    Vim and TextMate work well without extension.
    How is that?

    Here's a file: /usr/local/myfile

    What is it? Yup, you can't tell without opening it first, or TRYING to
    run it. If it has no shebang of execute bit, you're screwed. Now you
    have to open it to figure out how to run it.
    But we are talking about "script/myapp_server" with execute bit.


    --
    sebastian
  • Christopher H. Laco at Nov 19, 2005 at 6:23 pm

    Sebastian Riedel wrote:
    Am 19.11.2005 um 18:16 schrieb Christopher H. Laco:
    How about some more fact rather than a quip?
    I believe SciTE is a rather well known non broken editor in that
    reqpest. I would wager that the majority of all editors check the file
    extension as the very first check in mapping files to languages and
    language parsers.

    I would also argue that having an editor guess what my file is by it's
    contents is more prone to error than the file extension.

    Vim and TextMate work well without extension.

    That's nice. I'm not on a mac, and not everyone uses vim/emacs.
    LEt's not get into thew editor wars. My point is, let's not hinder
    peoples abilites just because one attendee is afraid of file extensions.
    How is that?

    Here's a file: /usr/local/myfile

    What is it? Yup, you can't tell without opening it first, or TRYING to
    run it. If it has no shebang of execute bit, you're screwed. Now you
    have to open it to figure out how to run it.

    But we are talking about "script/myapp_server" with execute bit.
    My point stands. It's a consistancy thing. All perl files should have
    there proper extensions. Having some with, and some without just creates
    more confusion.
  • Corey at Nov 19, 2005 at 11:40 am

    On Saturday November 19 2005 5:28 pm, Christopher H. Laco wrote:
    Sebastian Riedel wrote:
    Vim and TextMate work well without extension.
    That's nice. I'm not on a mac, and not everyone uses vim/emacs.
    LEt's not get into thew editor wars.
    +1

    ( although I do use vim - I still agree with Christopher's point )

    My point stands. It's a consistancy thing. All perl files should have
    there proper extensions. Having some with, and some without just creates
    more confusion.
    +2
  • Bill Moseley at Nov 19, 2005 at 6:31 pm
    I vote for no extensions. My /usr/bin is full of "programs" that are
    of various types w/o extensions.


    $file .= '.pl' if $^O eq 'MSWin32';

    or

    -add_pl_to_scripts

    or

    print "You seem to be running on a shebangless system.
    Add .pl to your scripts? [y]/n: ";




    --
    Bill Moseley
    moseley@hank.org
  • Christopher H. Laco at Nov 19, 2005 at 6:36 pm

    Bill Moseley wrote:
    I vote for no extensions. My /usr/bin is full of "programs" that are
    of various types w/o extensions.


    $file .= '.pl' if $^O eq 'MSWin32';

    or

    -add_pl_to_scripts

    or

    print "You seem to be running on a shebangless system.
    Add .pl to your scripts? [y]/n: ";
    Well, OS scripts are a different story. There, no extension makes sense.
    For instance, in FreeBSD, some were converted over time from bash, ro
    perl, to c. THeir names not changing was a good thing. I don't believe
    that applies to userland perl files with th same imortance.


    Now as for no extensions on *nix, and extensions on WIndows, that leads
    to more problems. Now when you refer to a script in documentation, you
    have to mention that fact that it's not named the same thing on
    different platforms.

    - -=Chris
  • Ben Norman at Nov 30, 2005 at 4:58 am
    My generated classes dont seem to be getting married up to my loaded tables.
    What am I missing to make this happen?
    And what is the _db class for?

    thanks
    ben

    [Wed Nov 30 14:26:04 2005] [catalyst] [debug] Loaded tables "tkey tuser
    user_key"
    [Wed Nov 30 14:26:05 2005] [catalyst] [debug] Loaded components:
    .-------------------------------------------------------------------+----------.
    Class | Type |
    +-------------------------------------------------------------------+----------+
    Keys::Model::DBIC | instance |
    Keys::Model::DBIC::Tkey | class |
    Keys::Model::DBIC::Tuser | class |
    Keys::Model::DBIC::UserKey | class |
    Keys::Model::DBIC::_db | class |
    Keys::View::TT | instance |
    '-------------------------------------------------------------------+----------'


    ----------------------------------------------------------------
    This message was sent using IMP, the Internet Messaging Program.
  • Bill Moseley at Nov 19, 2005 at 6:56 pm

    On Sat, Nov 19, 2005 at 06:26:24PM +0100, Sebastian Riedel wrote:
    I would also argue that having an editor guess what my file is by it's
    contents is more prone to error than the file extension.
    Vim and TextMate work well without extension.
    I seem to run those catalyst scripts than edit them.

    --
    Bill Moseley
    moseley@hank.org
  • Sebastian Riedel at Nov 19, 2005 at 6:46 pm

    Am 19.11.2005 um 01:26 schrieb Sebastian Riedel:

    This question came up after the web frameworks night yesterday,
    many people seem to think it's ugly.
    Should we remove the .pl extension from scripts?
    Ok, seems we have a clear no, extensions have to stay.


    --
    sebastian
  • Johan Lindström at Nov 19, 2005 at 8:32 pm

    At 18:54 2005-11-19, you wrote:
    Should we remove the .pl extension from scripts?
    Ok, seems we have a clear no, extensions have to stay.
    Thank you, this was turning into a bike shed discussion :)
    http://www.petesh.com/archives/2004/10/why_should_i_care_what_color_t.html


    /J
  • Christopher H. Laco at Nov 19, 2005 at 8:35 pm

    Johan LindstrXm wrote:
    At 18:54 2005-11-19, you wrote:

    Should we remove the .pl extension from scripts?

    Ok, seems we have a clear no, extensions have to stay.

    Thank you, this was turning into a bike shed discussion :)
    http://www.petesh.com/archives/2004/10/why_should_i_care_what_color_t.html
    ha ha. I haven't heard that term in a while. :-)
  • Christopher Hicks at Nov 20, 2005 at 2:44 pm

    On Sat, 19 Nov 2005, Sebastian Riedel wrote:
    Am 19.11.2005 um 01:26 schrieb Sebastian Riedel:
    This question came up after the web frameworks night yesterday, many people
    seem to think it's ugly.
    Should we remove the .pl extension from scripts?
    Ok, seems we have a clear no, extensions have to stay.
    That's sad. Why not leave the "proper" files there with their full .pl
    extension glory and for people who are in "open standards compliant"
    enviroments (like everything but Windows these days) offer a little
    convenience and toss in a symlink? Putting in symlinks doesn't screw up
    editing anything and it saves three keystrokes every time you type one of
    these things all the way out. It LOOKS hella nicer too.

    Extensions have been left out of UNIX commands for a variety of very good
    reasons for 35 years now. Relying on extensions as ways of seperating
    file types may be more convenient if portability to Windows is a concern,
    but otherwise they're simply clutter. The Mac had had metadata forks
    since Day 1 and the FOSS world has has file magic for 20+ years now.
    Relying on file extensions is just so reminiscent of the idiot driver who
    followed the Exit Here sign that had fallen askew and ended up landing in
    the ditch. It would seem you wouldn't have to do this too many times to
    realize where the authoritative information actually is, but computers are
    immune to common sense it often seems. The lure of treating file
    extensions as real information is admittedly understandable, but given
    that other clearly better solutions exist for the same stuff its only a
    matter of time before noone treats extensions as significant anymore.
    8.3 filenames died not only from excess of brevity, but because every
    filename had a superfulous dot in it! :)

    But honestly, shouldn't it be enough that we don't want to make users know
    what language every command is written in? Maybe we want to replace these
    things with shell and batch scripts someday. Ok, that's not entirely
    serious, but still, the user doesn't, shouldn't, and won't care what
    language command line commands are written in. Is you cp Perl or C or
    C++? How about your cc? What language is your Perl written in? Aside
    from Windows own band-aid of hiding file extensions by default, you might
    want to recall/realize that our very own Sun Microsystems tweaked things
    in Solaris to run SomeRandomJava.class files as simply SomeRandomJava.

    Its pretty funny watching so many half-as$ed attempts at burying file
    extensions, but if the extensions would just stay buried it wouldn't still
    be a problem. :)

    --
    </chris>

    There are two ways of constructing a software design. One way is to make
    it so simple that there are obviously no deficiencies. And the other way
    is to make it so complicated that there are no obvious deficiencies.
    -- C.A.R. Hoare
  • Aaron Peterson at Nov 20, 2005 at 3:32 pm

    On 11/20/05, Christopher Hicks wrote:
    On Sat, 19 Nov 2005, Sebastian Riedel wrote:
    Am 19.11.2005 um 01:26 schrieb Sebastian Riedel:
    This question came up after the web frameworks night yesterday, many people
    seem to think it's ugly.
    Should we remove the .pl extension from scripts?
    Ok, seems we have a clear no, extensions have to stay.
    That's sad. Why not leave the "proper" files there with their full .pl
    extension glory and for people who are in "open standards compliant"
    enviroments (like everything but Windows these days) offer a little
    convenience and toss in a symlink? Putting in symlinks doesn't screw up
    editing anything and it saves three keystrokes every time you type one of
    these things all the way out. It LOOKS hella nicer too.

    Extensions have been left out of UNIX commands for a variety of very good
    reasons for 35 years now. Relying on extensions as ways of seperating
    file types may be more convenient if portability to Windows is a concern,
    but otherwise they're simply clutter. The Mac had had metadata forks
    since Day 1 and the FOSS world has has file magic for 20+ years now.
    Relying on file extensions is just so reminiscent of the idiot driver who
    followed the Exit Here sign that had fallen askew and ended up landing in
    the ditch. It would seem you wouldn't have to do this too many times to
    realize where the authoritative information actually is, but computers are
    immune to common sense it often seems. The lure of treating file
    extensions as real information is admittedly understandable, but given
    that other clearly better solutions exist for the same stuff its only a
    matter of time before noone treats extensions as significant anymore.
    8.3 filenames died not only from excess of brevity, but because every
    filename had a superfulous dot in it! :)

    But honestly, shouldn't it be enough that we don't want to make users know
    what language every command is written in? Maybe we want to replace these
    things with shell and batch scripts someday. Ok, that's not entirely
    serious, but still, the user doesn't, shouldn't, and won't care what
    language command line commands are written in. Is you cp Perl or C or
    C++? How about your cc? What language is your Perl written in? Aside
    from Windows own band-aid of hiding file extensions by default, you might
    want to recall/realize that our very own Sun Microsystems tweaked things
    in Solaris to run SomeRandomJava.class files as simply SomeRandomJava.

    Its pretty funny watching so many half-as$ed attempts at burying file
    extensions, but if the extensions would just stay buried it wouldn't still
    be a problem. :)

    --
    </chris>
    I agree about the sillyness of the extension convention. But come on
    man, how hard can it be to make your own links, or use tab completion
    if 3 keystrokes is a big concern for you. Think we're going to change
    the way Microsoft likes to do things any time soon?

    Aaron
  • David Storrs at Nov 20, 2005 at 5:35 pm

    On Nov 20, 2005, at 8:49 AM, Christopher Hicks wrote:
    On Sat, 19 Nov 2005, Sebastian Riedel wrote:
    Am 19.11.2005 um 01:26 schrieb Sebastian Riedel:
    This question came up after the web frameworks night yesterday,
    many people seem to think it's ugly.
    Should we remove the .pl extension from scripts?
    Ok, seems we have a clear no, extensions have to stay.
    That's sad. Why not leave the "proper" files there with their
    full .pl extension glory and for people who are in "open standards
    compliant" enviroments (like everything but Windows these days)
    offer a little convenience and toss in a symlink? Putting in
    symlinks doesn't screw up editing anything and it saves three
    keystrokes every time you type one of these things all the way
    out. It LOOKS hella nicer too.

    Extensions have been left out of UNIX commands for a variety of
    very good reasons for 35 years now. Relying on extensions as ways
    of seperating file types may be more convenient if portability to
    Windows is a concern, but otherwise they're simply clutter. The
    Mac had had metadata forks since Day 1 and the FOSS world has has
    file magic for 20+ years now. Relying on file extensions is just so
    reminiscent of the idiot driver who followed the Exit Here sign
    that had fallen askew and ended up landing in the ditch. It would
    seem you wouldn't have to do this too many times to realize where
    the authoritative information actually is, but computers are immune
    to common sense it often seems. The lure of treating file
    extensions as real information is admittedly understandable, but
    given that other clearly better solutions exist for the same stuff
    its only a matter of time before noone treats extensions as
    significant anymore. 8.3 filenames died not only from excess of
    brevity, but because every filename had a superfulous dot in it! :)

    But honestly, shouldn't it be enough that we don't want to make
    users know what language every command is written in? Maybe we
    want to replace these things with shell and batch scripts someday.
    Ok, that's not entirely serious, but still, the user doesn't,
    shouldn't, and won't care what language command line commands are
    written in. Is you cp Perl or C or C++? How about your cc? What
    language is your Perl written in? Aside from Windows own band-aid
    of hiding file extensions by default, you might want to recall/
    realize that our very own Sun Microsystems tweaked things in
    Solaris to run SomeRandomJava.class files as simply SomeRandomJava.

    Its pretty funny watching so many half-as$ed attempts at burying
    file extensions, but if the extensions would just stay buried it
    wouldn't still be a problem. :)
    Chris,

    Thanks for your points. A few thoughts for you:

    1) I think sri already made the call, and I think he has the moral
    authority to make it.

    2) As Aaron Peterson said before I could type this, tab completion
    answers your keystrokes issue.

    3) I for one do not want symlinks: I don't want twice as many files
    sitting around, one set with and one set without extensions.

    4) You failed to address the most compelling point which is that
    file extensions are useful *to humans*. Being able to glance at a
    list of files and recognize the Perl ones is useful. Yes, I could
    run 'file' on each of them--if I was on an operating system that had
    'file'--but that takes longer than a casual glance. I do not feel
    that I should be put out to satisfy someone else's sense of aesthetics.

    5) This *is* a question of pure aesthetics. That's it, nothing
    more. It's a bikeshed, let it go.

    Folks, this is purely a matter of taste. There are no major issues
    here of any kind. If you don't like the extensions, rename the files
    to get rid of them. But please, stop flooding the list.

    </rant>

    --Dks

Related Discussions

People

Translate

site design / logo © 2022 Grokbase