This is generally a problem with script repositories. The owners never do any kind of quality assurance on the scripts that they list. I often find my scripts listed next to Matt's scripts and the like. Usually you'll find that the owner of these archives don't have the knowledge to comment on the quality of these scripts.

I don't really like discussing things before they're ready to go live, but you might be interested to know that london.pm is currently working on a set of replacements for Matt's scripts. Hopefully I'll be in a position to say more in a week or two.

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

Ignoring the "local", notice the typo in the tr///;

sub ucase {
    local($s1) = @_;
    $s1 =~ tr/[a-z]/[A-Z}/;
 return $s1;
}
[download]

$chk =~ /(.*@.*\.[a-zA-Z]{2,3}$)/ && $chk !~ /(^\.)|(\.$)|( )|(\.\.)|(
+@\.)|(\.@)|(@.*@)/
[download]

sub readem {
        local $insFile = shift; local $back = "";
    if (open(FL, "<$insFile")) {
        while (<FL>) {$back .= $_;}
    close(FL);    } else {&showErr('Fatal File Read Error');}
    return $back;
}
[download]

Hmmm... I wonder how he parses form data (incidentally, he reproduces the following code in many different files. If he tries to fix any of the bugs, he's got many different places to fix it in):

    @pairs = split(/&/, $query_string);
    foreach $pair (@pairs) {
    ($name, $value) = split(/=/, $pair);
        $value =~ tr/+/ /;
        $name =~ tr/+/ /;
        $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
        $name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
        $value =~ s/~!/ ~!/g;
        $name =~ s/~!/ ~!/g;
        $value =~ s/<([^>]|\n)*>//g if $name ne "comtext" && $name ne 
+"ONld" && $name ne "edstext" && $name ne "mtxt"; 
        $name =~ s/<!--#(.|\n)*-->//g;
        $value =~ s/<!--#(.|\n)*-->//g;
        $value =~ s/("|')//g if $name ne "comtext" && $name ne "ONld" 
+&& $name ne "edstext" && $name ne "mtxt";
        $value =~ s/(`|\0|\\[^\\n])//g;
        $name =~ s/(`|\0|\\)//g;
    $FORM{$name} = $value;
    }
[download]

Okay, I'll stop now. I think the point is made :)

Cheers,
Ovid

Update: Ooh, ooh, stop me before I kill again! Here's another beauty:

sub date_time {
    my($s1) = @_;
    my($mon,$year);
   ($mon,$year) = (gmtime($s1))[4,5];
    $mon++;
    if ($year < 39) { $year = "20$year" }
    elsif ($year > 99 && $year < 2000) { $year = 2000 + ( $year - 100 
+) }
    elsif ($year > 38) { $year = "19$year" }
   return ($mon,$year);
}
[download]

$datetime = &date_time(&date_time(0));
[download]

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Is it appropriate to email someone to tell them how many problems they have with their code?

This is something I've been doing more and more recently. For example, the author of Date::MMDDYY has now removed his module from CPAN (tho' he said I wasn't the only person to write to him).

I think that as long as you're polite and point out why what they are doing is wrong, then it's a very positive thing to do.

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

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

Wow, date_time() is the clearest case of Missing The Point I've seen in a long time!

The best part is subtracting 100 from $year then adding 2000, but only if it's greater than 99 or less than 2000. Classic.

It's like Dostoyevsky wrote Perl -- paid by the line, a torturous and twisty romp through the mind of a killer.

(For people who don't know why that's wrong, gmtime and localtime and such return the year component as the number of years since 1900.)

Edited 2001-03-26 by Ovid

The beauty of the scripts and snippets that are posted here at the Monastery is the comments below them. If someone posts bad code, it will be pointed out very quickly. And if you see a snippet with no comments, feel free the check it out it and comment on it.

However, I feel that the only time you should 'cut and paste' someone else's code into 'your own' is when you know what the consequences will be. And if you don't . . . may Saint Wall have mercy on you soul.

Jeff

R-R-R--R-R-R--R-R-R--R-R-R--R-R-R--
L-L--L-L--L-L--L-L--L-L--L-L--L-L--

I sometimes think we need a "Consumer's Reports" for Perl packages.

Although I personally like depending on modules is a valueable thing in such a repository I think that scripts that don't need any other modules installed is a good thing. People that are searching for such scripts usually don't want to write ones themself and therefore depend on solutions that are easy to install. Without depending on modules makes the script even more useful to those guys. And the wish that it should not depend on an SQL database or flat file lets me think that the requester falls into this category. YMMV.

Finally I still think that there should be reasonably licenced stuff also in this list, I simply doubt that you belief every thing in the world should be GPLed (or better could). I also often dream of a brave new world ;-)
--
Alfie

alfie wrote:

I simply doubt that you belief every thing in the world should be GPLed (or better could).

I agree that not everything should be released under the GPL. My objection, in this case, is that the restrictive license ensures that I cannot fix any bugs or security holes. I doubt anyone would ever have heard of Perl or Linux if either had such a license, even for free.

In fact, I would probably go so far as to say that I don't want to work with any software product where I cannot be reasonably expected to fix it or have a serious bug fix quickly issued by the manufacturer. That being said, I seem to be stuck in the Windows world, so that puts the lie to my argument :)

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Based on past experience, I would guess that what Ovid saw is pretty much par for the course.

Also based on past experience, I would say that bad code which doesn't need modules does nobody a favour in the end.

As an exercise, why don't you go to the repository that you suggested and try to find a script from it that you would happily recommend? Would you care to bet on whether it would pass basic sanity checks when looked at by some of the knowledgable people here?

Well, in some cases I could understand not wanting to rely on modules so that the program is easier to install. Such as Date::Calc and the like who have compile-necessary parts, as well as a few others that simply have huge (or hugely complicated) installations. For the other (more common), less complicated modules, you could just bundle the modules you require with yours and have your install script install the needed modules as well (if they're not already there). They might not get the most recent version but it's sure to work.

I simply cannot agree, however, that one should avoid dependance upon modules bundled with the core distrubution of Perl (CGI, etc). There are few (if any) Perl installs that will be lacking these most basic of modules and there are many very useful modules bundled with Perl.

Anyway, I just had to say that as I'm always leery when I see people arguing, "Well, I figured it would be easier to install if I didn't rely on modules... So I wrote my own CGI parsing code."

Just my $0.02 -- Oh! I'm sorry, do you have change for a nickel?

bbfu
Seasons don't fear The Reaper.
Nor do the wind, the sun, and the rain.
We can be like they are.