http://www.perlmonks.org?node_id=53956

Hi; I am a beginning Perl programmer who has used Perl for about 6 months. I still code Perl like a C programmer and often still write in C. During my readings of various web resources I have noticed that the site called "Matt's Script Archives" is generally depricated. I am curious as to why. This is really a serious question.

What are some of the things found there that I should avoid? What better ways of doing things are there?

Your answers I hope will help me improve my abilities.
Thanks.

Replies are listed 'Best First'.
Neither is this
by footpad (Abbot) on Jan 24, 2001 at 21:10 UTC
    Update: Updated the link to the formmail.pl rant with the one I couldn't find this morning. thanks lemming!

    Adding to davorg's list, here are a few things that give me the willies from that site:

    • Many of the tools from that site haven't been updated since 1997. In itself, this should be a huge warning. Perl has evolved since that time. Wouldn't you rather use code that uses today's capabilities to their fullest? Additional security issues have been identified. Wouldn't you rather depend on something that's at least been modified in the last year?

    • The code doesn't use highly respected modules, such as CGI.pm. This means each script has to reinvent the wheel. It also means that it's up to the script's user to research and defend against newly identified security risks, such as DOS attacks. On the other hand, CGI.pm is continuously maintained and defends against these and other abuses.

      To be fair, MSA checks some things. However, the code doesn't even cover the basics discussed in the documentation provided with the language. To my mind, this is inexcusable.

    • The scripts do not use tainting, STRICT, or warnings. This is a huge red flag.

    • Error checking is minimal. For example, Guestbook fails to verify that the data file actually opened (or closed, for that matter). This suggests that users may run into problems in high traffic situations (e.g. two users trying to enter guestbook entries at the same time) or cryptic error (Server Error 500) messages that could have been detected and handled through simple defensive programming. Along the same lines, FormMail doesn't verify success when it opens the mail server.

    • The solutions are, in my opinion, superficial and not designed for maintenance or extension. For example, FormMail doesn't support attachments. Sure, you can retrofit that, but compare the source of FormMail.pl to this implementation by our resident wizard. Which would you rather use?

    • Similarly, data storage is handled through text files, which is fine for some things, but greatly limits you when you need more. I would much rather see WWWBoard use DBI::CSV (at the very least; a real database would be preferred) than its current implementation. At a bare minimum, I'd like to see some file locking added.

    • The book sold through the site "devotes" eight pages to security (as an appendix, mind you), but the discussion is so superficial, it's almost useless. There are a few good ideas, but when you compare his material to documentation provided with Perl, the FAQ available on perl.com, the 19-page discussion in the Rat book, the 28-page discussion in Camel3 and related posts in the Monastery (the ones with high reputations), it becomes pretty clear that the reason his discussion is so short is due to inexperience (optimistically) or neglect (pessimistically).

      Frankly, I don't want to trust my servers to code that treats such an important subject so cavalierly.

    While I understand that one might play the "self-contained" card, my problem with that argument is simple: By limiting your access to the experts and their works, you force yourself to become an expert in every area. It would be more apropriate to combine the best modules the community has to offer, so that newbies can learn from good code done well, as opposed to restricted solutions done poorly.

    That's not to say that you can't learn things from the code provided there; however, I would be extremely cautious deploying anything from there. Frankly, there are better resources and solutions.

    What's most frustrating is that the site is often one of the first places people find when they start looking for Perl CGI scripts. They innocently assume that the code is fine ("After all, it hasn't needed an update since 1997." And, yes, I've actually heard this said) and then wonder why problems occur.

    If you're really looking to improve your capabilities, register here, scour the archives, read the home nodes (and the links found there), and start participating. You'll get quality feedback from experienced, helpful people. You'll find code that works more reliably, is more flexible, and provides more overall benefit than the abandon-ware on that other site.

    --f

    P.S. Sorry if this is overly harsh; it's meant as constructive criticism. If MW participates here, I hope he'll take the feedback to heart and rework his free offerings so that they demonstrate more effective, appropriate, and secure practices.

Re: This is not Flamebait
by davorg (Chancellor) on Jan 24, 2001 at 16:53 UTC

    A number of points:

    • The scripts there are written in a really bad style.
    • Matt doesn't seem to know about CPAN. He doesn't use modules in any of his scripts.
    • There are serious security flaws in most of the scripts (for example he never uses -T).

    Is that enough to be going on with?

    --
    <http://www.dave.org.uk>

    "Perl makes the fun jobs fun
    and the boring jobs bearable" - me

Re: This is not Flamebait
by InfiniteSilence (Curate) on Jan 24, 2001 at 23:54 UTC
    I actually uploaded and implemented the FormMail script upon the suggestion of hypermart who is hosting my site. I did not bother to 'look under the hood'. This was stupid, I admit, but I know that Hypermart intercepts outgoing mail from their servers and sends it only to the registered site administrator anyway.

    I wanted to make a change to the code and get rid of the god-awful ugly 'echo-of-form-variables' that comes back to you when you submit. Looking at the code I noticed no CGI! It was a bunch of hard coded html sprawled everywhere. I couldn't modify it. The only thing I could reuse out of the entire thing was the path to Hypermart's q-mail inject program.

    Celebrate Intellectual Diversity

      And worse yet, there are people who are out there searching for perl code to learn from. Lo-and-behold, they find "a bunch of hard coded html sprawled everywhere" instead of CGI, and end up coding like crap until they discover that they've been deceived. Speaking from personal experience...

      I can understand how those scripts are created to run on any bass ackwards install that doesn't include any modules (since there are hosting providers who are retarded), but REALLY now!?!? You have to draw the line somewhere...

      - dystrophy -
Re: This is not Flamebait
by a (Friar) on Jan 30, 2001 at 10:06 UTC
    and, out of deference to our own deprecated (and a grandmother and mother who were english teachers):
    • Deprecate: To pray against, as an evil; to seek to avert by prayer; to desire the removal of; to seek deliverance from; to express deep regret for; to disapprove of strongly.

      His purpose was deprecated by all round him, and he was with difficulty induced to adandon it. --Sir W. Scott.

    • Depreciate: To lessen in price or estimated value; to lower the worth of; to represent as of little value or claim to esteem; to undervalue. --Addison.

      Which . . . some over-severe phoilosophers may look upon fastidiously, or undervalue and depreciate. --Cudworth.

      To prove that the Americans ought not to be free, we are obliged to depreciate the value of freedom itself. --Burke.

      Syn: To decry; disparage; traduce; lower; detract; underrate.

    (from The Exploding Dictionary )

    a