Which package from CPAN should I use to send mail?
Sometime the timtowtdi approach is very tiring. For me, especially when it comes to package selection.
So all I want is to send email, potentially HTML emails. Between Mail-Sendmail, Mail-Sender, NET-SMTP (by the way - not available in PPM), Mail-SendEasy, and the 80 or so other packages that have 'Mail' in their package name - which one should I choose?
And while in this subject, what is your general apprach to choose the "canonical" package for a jog. I.e. the package that "everybody is using". Is there any rating or popularity billboard somewhere?
what is your general apprach to choose the "canonical" package for a jog. I.e. the package that "everybody is using". Is there any rating or popularity billboard somewhere?
When I want to pick which of several CPAN modules to use, the things I look at are
Documentation:
The litmus test for CPAN modules is the first page of the documentation. If there is a messy synopsis, or a synopsis without a simple working example, I guess that the module is probably not a good one. Untidy, messy, or misformatted documentation is also a red flag.
State of repair:
the date of release of the last version of the module tells you if it is being maintained,
the CPAN tester's reports tell you whether the module is likely to install without a struggle
the bugs list on rt.cpan.org gives you some idea of how active the author is about maintaining the module.
Also, is there a mailing list for the module? Having a mailing list is a pretty good sign of a good-quality, maintained, stable, documented and popular module.
Author:
What is the name of the module author?
How many other modules has the author released?
What kind of modules has the author released?
The author is a big factor. There are some authors who create things which have excellent quality, like Gisle Aas, Graham Barr, Andy Wardley, or Jan DuBois, and some people who turn out a lot of things which could be described as "experimental", like Damian Conway or Tatsuhiko Miyagawa. Be wary of people who've released a lot of Acme:: (joke) modules. Also, beware of things written by people who only maintain one or two modules. People who have fewer than five modules in total usually don't maintain them.
Other things:
cpanratings.perl.org is often helpful, but take it with a grain of salt.
Apart from that, a lot of it is just trial and error. Download and see if it passes its own tests, see if it even has any tests, write a test script, etc.
Things which often don't give a meaningful ranking:
The top results on Google tend to be ancient Perlmonks or perl.com or Dr. Dobbs' Journal articles, and these often point you towards outdated things.
search.cpan.org's search function puts modules which haven't been updated for ten years on page one, and the latest and greatest on page ten or something.
Beware of "hype":
One more thing I want to say: Be wary of advice on blogs, stackoverflow, Usenet news, etc. - people tend to guide you to whatever module happens to be flavour of the month, rather than a stable, proven solution. The "trendy" modules usually lack documentation, are unstable, have nightmarish dependencies, and quite often yesterday's fashionable modules suddenly fall out of favour and are abandoned, to be replaced by another flavour of the month, leaving you in the lurch if you decide to use them.
Task::Kensho generally makes good recommendations. For sending email it suggests Email::Sender
I'll throw in Email::Stuff. It's a nice wrapper for Email::MIME. You don't need to care about the MIME structure of the mail, the module does it for you.
Email::Stuff->from ('cpan#ali.as' )
->to ('santa#northpole.org' )
->bcc ('bunbun#sluggy.com' )
->text_body($body )
->attach (io('dead_bunbun_faked.gif')->all,
filename => 'dead_bunbun_proof.gif')
->send;
As for selecting modules,
If you don't need more than the basic features, I suggest looking at Mime::Lite.
use MIME::Lite;
my $msg = new MIME::Lite
From => 'Your friendly neighbourhood spiderman',
To => 'green#goblin.net',
CC => 'info#nemesis.org',
BCC => 'mj#spidey.info',
'Reply-to' => 'enemies#spidey.info',
Subject => 'Please stop',
Data => $data; #Email body
die 'Could not send mail' unless ($msg->send);
You can use Email::Send
http://search.cpan.org/dist/Email-Send/lib/Email/Send.pm
What I prefer is
Mail::Sendmail
MIME::Lite
If you require SSL then include
Net::SMTP::SSL
Related
I building a web service, instead of using template system like toolkit I using package module like this:
Create pages urls, each page in independent module according to url previous create in the route,
pass as argument to every module a unique hash ref with variables for global title, footer, and all others data where is the same in each page (module).
main.pl
use strict;
use warnings;
use Handler;
my %mvs = (# my variables
username => $set{user},
titleglobal => '| web System ',
ip => $env->{REMOTE_ADDR}
.........
.........
);
for my $module_url (reverse #all_urls_names ) {
$router->add($module_url, sub {
$module_url->new(\%mvs);
})
}
In the module page, I have anothers modules who load header.pm, footer.pm but the body.pm is loaded directly in the current module page, in this case Handler.pm
Handler.pm
package Handler;
use strict;
use warnings;
use Layout::Head;
use Layout::Footer;
my $layout = sub {
my ($head, $body, $footer) = ( Head::new($mvs), thebody($mvs), Footer::new($mvs) );
return <<THE_HTML;
$head
$body
$footer
THE_HTML
};
return [ 200, [ "Content-Type" => "text/html" ], [ $layout->() ] ];
}
sub thebody{
.........
.........
}
I have done this approach having as reference the wordpress layout, all is working fine and good.
¿is this good way to building maintainable code ?
Note: I chose this way because I not want to install more modules.
(solves the given problem with the least amount of necessary code (less code to debug - obvious speedup)
You say that your constraint is not installing modules. But, what's the on-the-ground difference between installing prewritten modules and creating new ones?
Maybe you have issues with deployment. That's understandable. However, you can use things such as Carton to create applications. Set up everything on a system where you have the flexibility you need to deploy to a system where you don't.
With many CPAN modules you can take the libraries directly from the distribution and reuse them. If they don't use XS or need external libraries (say, like, openssl), they are able to run out of the box.
I don't particularly advise this, but it's doable. You get widely tested modules and the community support that comes with it. That's less code to debug because someone else already did the work! These things are complicated systems and you are going to have to do quite a bit of work to not only debug what you've done but discover everything else that you should have done and supported. Having reinvented a few things myself, I've learned my lesson.
Everyone eventually writes their own templating system (and everyone should as part of their life experience). That's fine. However, you should study what other systems do and how they do it so you don't repeat their mistakes. Some templating modules are small and simple and can be the basis for your explorations. Check out Text::Template for example: it's two module files and no dependencies. Going through this exercise shows you the hidden depths and complexities of what you are trying to do.
If you are making a web framework, have you looked at Mojolicious? It is a self-contained system that only requires core Perl modules (although you'll likely still need other things like a database connection and so on). It has a nice templating system. For something lighter weight (but how much lighter can you get), your approach looks like CGI::Prototype. Take a look at that.
Lastly, avoiding modules because you're anxious about installing anything might be something you just need to confront and get it over with. Almost any system is a bit scary at first and gets better after you get used it and learns how it works. You might not like CPAN (but what does "like" have to do with getting work done?), but perhaps you can get what you need from system packages already. In the end you want to get more work done. A little work at the front can save you a lot of work at the end.
We're here to help when you run into problems installing modules! :)
Is this good way to build maintainable code?
No.
At the heart of your system you have HTML (and, perhaps, CSS and Javascript) embedded in your Perl code. This might look like a good idea when it's just you maintaining the site, but when you get successful enough to need a separate front-end development team, you'll realise what a terrible idea it is.
Also, you are reinventing wheels. There are many great web frameworks and templating systems available on CPAN. Most of them have been used in production by lots of people over many years. They will have more features than your code and will be far better tested.
You say you're doing this because you don't want to install more modules. I urge you to reconsider this approach. Most modern Perl programming consists of plumbing together the right CPAN modules. You will be needlessly restricting the power of the language.
I am trying to localize a CPAN module MooX::Options using Locale::TextDomain after having read "On the state of I18N in perl".
In the discussion in the pull request the question came up how to deal with messages not originating in the module itself, but in a dependency. In this specific case, when you specify an option on the command line which is not defined anywhere in the code, you'll get the warning:
Unknown option: xyz
originating in the module Getopt::Long, which in itself is not localized yet.
The question is how to deal with these. I see basically three strategies:
Ignore them, which I find dissatisfactory.
Try to someway or other catch all the corner cases and messages in the module I'm currently localizing (in this case MooX::Options), and this way working around the missing localization in the dependent modules. This option seems brittle, as I'd have to constantly adapt to changes in the base modules. Sometimes, it might by next to impossible to catch messages, as they're written to output streams directly by the modules (as is the case in this example).
Try to localize the dependent modules themselves. This option seems hard to achieve, as different projects might use different I18N tools and strategies themselves and the dependency graph might be huge.
All in all, I think this problem is more general and not that specific to perl and cpan modules. So, I'm interessted in your thoughts, strategies and approaches.
I have rather strong opionions on the idea of translating computing terms, and most people disagree with my views, so take what I am saying with a grain of salt.
I do not understand the point of internationalizing a library for parsing command line options unless you want to further ghettoize what is already a small group of users of said library.
Would wget be more useful to Turkish users if instead it was called wal or wgetir? Or, instead of wget --mirror, should Turkish users write getir --ayna? What about that w?
If you just translate the messages, what is the point of outputting a help message in response to wget -h when the Turkish equivalent would be wget -y?
The fact is, almost all attempts at translating programming related terms I have seen are simply awful. The people who are most eager to translate are usually not in command of either human language — Nor do they seem to understand what they are translating.
However, as a result of these eager people, I find that at least the Turkish translations of pretty much any software I touch is just awful. Whatever Danish translations I have seen did not fare much better, but, at least, they were tolerable owing to the greater commonality of structure between Danish and English.
I think everyone's energy is better spent on actually making sure their programs handle content, including names of external resources/references, in different languages well, rather than giving me error messages in some Frankenstein language, or letting me specify command line options whose mnemonics do not match their descriptions etc, or presenting menus that contain of strings of words that really do not convey any meaning.
I have felt this way for the last for many decades now ... Even when I was patching IBM PC keyboard drivers with hex editors so people at various places could type reports in WordStar, and create charts in Harvard Graphics.
So, my unpopular advice is to put your energy elsewhere ...
For example, use exception objects so the user of your library (who is likely a programmer and will understand "Directory not found" much more readily than "Kütük bulunamadı") can deduce in a human-language independent way what happened, and what message to show the user. I haven't looked closely at MooX::Options, but I notice there is at least one string croak.
Here is an actual error message from an IBM product:
Belirtilen kütük örüntüsüyle eşleşen hiçbir kütük bulunamadı
You can ask every one of the almost 200 million Turkic people on earth what a "kütük örüntüsü" is, and only the person who actually came up with this non-sensical string of characters will be able to tell you that it corresponds to "file pattern". What, then, do they gain by using the phrase "kütük örüntüsü" versus "file pattern"? Nothing.
However, they lose the ability to communicate with, and, also, compete with, programmers in the English speaking world.
PS: Apologies for all Turkish examples, but I feel most comfortable drawing abominable examples based on my native language.
I'm going into writing some crawlers for a web-site, the idea is that the site will use some back-end Perl scripts to fetch data from other sites, my design (in a very abstract way..) will be to write a package, lets say:
package MyApp::Crawler::SiteName
where site name will be a module / package for crawling specific sites, I will obviously will have other packages that will be shared across different modules, but that not relevant here.
anyway, making long short, my question is: Why (or why not...) should I prefer Moose over Standard OO Perl?
While I disagree with Flimzy's introduction ("I've not used Moose, but I have used this thing that uses Moose"), I agree with his premise.
Use what you feel you can produce the best results with. If the (or a) goal is to learn how to effectively use Moose then use Moose. If the goal is to produce good code and learning Moose would be a distraction to that, then don't use Moose.
Your question however is open-ended (as others have pointed out). There is no answer that will be universally accepted as true, otherwise Moose's adoption rate would be much higher and I wouldn't be answering this. I can really only explain why I choose to use Moose every time I start a new project.
As Sid quotes from the Moose documentation. Moose's core goal is to be a cleaner, standardized way of doing what Object Oriented Perl programmers have been doing since Perl 5.0 was released. It provides shortcuts to make doing the right thing simpler than doing the wrong thing. Something that is, in my opinion, lacking in standard Perl. It provides new tools to make abstracting your problem into smaller more easily solved problems simpler, and it provides a robust introspection and meta-programming API that tries to normalize the beastiary that is hacking Perl internals from Perl space (ie what I used to refer to as Symbol Table Witchery).
I've found that my natural sense of how much code is "too much" has been reduced by 66% since I started using Moose[^1]. I've found that I more easily follow good design principles such as encapsulation and information hiding, since Moose provides tools to make it easier than not. Because Moose automatically generates much of the boiler-plate that I normally would have to write out (such as accessor methods, delegate methods, and other such things) I find that it's easier to quickly get up to speed on what I was doing six months ago. I also find myself writing far less tricky code just to save myself a few keystrokes than I would have a few years ago.
It is possible to write clean, robust, elegant Object Oriented Perl that doesn't use Moose[^2]. In my experience it requires more effort and self control. I've found that in those occasions where the project demands I can't use Moose, my regular Object Oriented code has benefitted from the habits I have picked up from Moose. I think about it the same way I would think about writing it with Moose and then type three times as much code as I write down what I expect Moose would generate for me[^3].
So I use Moose because I find it makes me better programmer, and because of it I write better programs. If you don't find this to be true for you too, then Moose isn't the right answer.
[^1]: I used to start to think about my design when I reached ~300 lines of code in a module. Now I start getting uneasy at ~100 lines.
[^2]: Miyagawa's code in Twiggy is an excellent example that I was reading just today.
[^3]: This isn't universally true. There are several stories going around about people who write less maintainable, horrific code by going overboard with the tools that Moose provides. Bad programmers can write bad code anywhere.
You find the answer why to use Moose in the Documentation of it.
The main goal of Moose is to make Perl 5 Object Oriented programming easier, more consistent, and less tedious. With Moose you can think more about what you want to do and less about the mechanics of OOP.
From my experience and probably others will tell you the same. Moose reduces your code size extremly, it has a lot of features and just standard features like validation, forcing values on creation of a object, lazy validation, default values etc. are just so easy and readable that you will never want to miss Moose.
Use Moose. This is from something I wrote last night (using Mouse in this case). It should be pretty obvious what it does, what it validates, and what it sets up. Now imagine writing the equivalent raw OO. It's not super hard but it does start to get much harder to read and not just the code proper but the intent which can be the most important part when reading code you haven't seen before or in awhile.
has "io" =>
is => "ro",
isa => "FileHandle",
required => 1,
handles => [qw( sysread )],
trigger => sub { binmode +shift->{io}, ":bytes" },
;
I wrote a big test class last year that also used the handles functionality to redispatch a ton of methods to the underlying Selenium/WWWMech object. Disappearing this sort of boilerplate can really help readability and maintenance.
I've never used Moose, but I've used Catalyst, and have extensive experience with OO Perl and non-OO Perl. And my experience tells me that the best method to use is the method you're most comfortable using.
For me, that method has become "anything except Catalyst" :) (That's not to say that people who love and swear by Catalyst are wrong--it's just my taste).
If you already have the core of a crawler app that you can build on, use whatever it's written in. If you're starting from scratch, use whatever you have the most experience in--unless this is your chance to branch out and try something new, then by all means, accomplish your task while learning something new at the same time.
I think this is just another instance of "which language is best?" which can never be answered, except by the individual.
When I learned about objects in Perl, first thing I thought was why it's so complicated when Perl is usually trying to keep things simple.
With Moose I see that uncomplicated OOP is possible in Perl. It sort of bring OOP of Perl back to manageable level.
(yes, I admit, I don't like perl's object design.)
Although this was asked 10 years ago, much has changed in the Perl world. I think most people now see that Moose didn't deliver all people thought it might. There are several derivative projects, lots of MooseX shims, and so on. That much churn is the code smell of something that's close to useful but not quite there. Even Stevan Little, the original author, was working on it's replacement, Moxie, but it never really went anywhere. I don't think anyone was ever completely satisfied with Moose.
Currently, the future is probably not Moose, irrespective of your estimation of that framework. I have a chapter for Moose in Intermediate Perl, but I'd remove it in the next edition. That's not a decision from quality, just on-the-ground truth from what's happening in that space.
Ovid is working on Corrina, a similar but also different framework that tries to solve some of the same problems. Ovid outlines various things he wants to improve, so you can use that as a basis for your own decision. No matter what you think about either Moose or Corrina, I think the community is now transitioning out of its Moose phase.
You may want to listen to How Moose made me a bad OO programmer, a short talk from Tadeusz Sośnierz at PerlCon 2019.
Even if your skeptical, I'd say try Moose in a small project before you commit to reconfiguring a large codebase. Then, try it in a medium project. I tend to think that frameworks like Moose look appealing in the sorts of examples that fit on a page, but don't show their weaknesses until the problems get much more complex. Don't go all in until you know a little more.
You should at least know the basics of Moose, though, because you are likely to run into other code that uses it.
The Perl 5 Porters may even include this one in core perl, but a full delivery may happen in the five to ten year range, and even then you'd have to insist on a supported Perl. Most people I encounter are about three to five years behind on Perl versions. If you control your perl version, that's not a problem. Not everyone does though. Holding out for Corrina may not be a good short-term plan.
What are the popular, contemporary uses for Perl?
Edit
I should have been more specific. I was wondering more on the large scale (popular) what people are using Perl for rather than what it could be used for on the individual level.
As a glue language, system administrators' language, and now, it is back to taking-over-the-internet using Catalyst.
At my University Perl is widely used for Bioinformatic tasks. Automatic changing the format of a Proteindata file, checking with a database transforming the results back and so on.
So its mostly changing file formats, regular expressions, and parsing of huge datasets
The same as ever: Making the impossible, possible. ;-)
Along with Python, the system administrators in my company love it for driving automation tasks. "If something is worth doing, it's worth automating" seems to be a mantra, and if they can do it in five lines, all the better.
The problem with this question, is that Perl is a very versatile language. Between code golf and it's similarity to awk/sed, it is still widely used as a glue language and quick go-to language for sysadmin tasks.
With CPAN, lots of very useful and more advanced things can be written quickly.
It interfaces well with databases and there are tons of frameworks for web design. It works quite well with Ajax, as I've noticed through my own use of it.
Get into best practices, and you've got a system that is quite good at doing very large programming tasks. Heck, the whole of cpan is a testament to Perl's reusability and encapsulation.
See skills that are being sought by employers at http://jobs.perl.org/.
Somewhat confused by the question. For coding.
I think it would be better framed as: What isn't Perl used for? Which I'd answer with: Writing device drivers, anyone got any more?
It's used for gui apps (See Padre), Internet apps (Catalyst), other networking/sockets (POE), accessing databases (DBI), Cryptology (Crypt namespace), Web services (SOAP), Handling binary formats (pack/unpack)...
And of course all manner of text processing.
And that's just the stuff I've used it for.. recently.
Amazon and IMDB uses Perl, more specifically Mason, IIANM.
I currently am using Perl to write an automated testing suite for my company's web sites (using WWW::Mechanize and WWW::Selenium). One of my co-workers is doing the same for other types of servers. We also use it for our monitoring software (Nagios). And I use perl daily as a commandline tool to aid in basic sysadminy tasks.
I wrote a short, simple script to parse some data out of a log file recently. I find it pretty easy and useful for quick scripting tasks.
Try running this with the terminal size set to at least 120x50 and you will be enlightened ;).
#
sub j(\$){($
P,$V)= #_;while($$P=~s:^
([()])::x){ $V+=('('eq$1)?-32:31
}$V+=ord( substr( $$P,0,1,""))-74} sub a{
my($I,$K,$ J,$L)=#_ ;$I=int($I*$M/$Z);$K=int(
$K*$M/$Z);$J=int($J*$M /$Z);$L=int($L*$M/$Z); $G=$
J-$I;$F=$L-$K;$E=(abs($ G)>=abs($F))?$G:$F;($E<0) and($
I,$K)=($J,$L);$E||=.01 ;for($i=0;$i<=abs$E;$i++ ){ $D->{$K
+int($i*$F/$E) }->{$I+int($i*$G/$E)}=1}}sub p{$D={};$
Z=$z||.01;map{ $H=$_;$I=$N=j$H;$K=$O=j$H;while($H){$q=ord
substr($H,0,1,"" );if(42==$q){$J=j$H;$L=j$H}else{$q-=43;$L =$q
%9;$J=($q-$L)/9;$L=$q-9*$J-4;$J-=4}$J+=$I;$L+=$K;a($I,$K,$J,$ L);
($I,$K)=($J,$L)}a($I,$K,$N,$O)}#_;my$T;map{$y=$_;map{ $T.=$D->{$y}
->{$_}?$\:' '}(-59..59);$T.="\n"}(-23..23);print"\e[H$T"}$w= eval{
require Win32::Console::ANSI};$b=$w?'1;7;':"";($j,$u,$s,$t,$a,$n,$o
,$h,$c,$k,$p,$e,$r,$l,$C)=split/}/,'Tw*JSK8IAg*PJ[*J#wR}*JR]*QJ[*J'.
'BA*JQK8I*JC}KUz]BAIJT]*QJ[R?-R[e]\RI'.'}Tn*JQ]wRAI*JDnR8QAU}wT8KT'.
']n*JEI*EJR*QJ]*JR*DJ#IQ[}*JSe*JD[n]*JPe*'.'JBI/KI}T8#?PcdnfgVCBRcP'.
'?ABKV]]}*JWe*JD[n]*JPe*JC?8B*JE};Vq*OJQ/IP['.'wQ}*JWeOe{n*EERk8;'.
'J*JC}/U*OJd[OI#*BJ*JXn*J>w]U}CWq*OJc8KJ?O[e]U/T*QJP?}*JSe*JCnTe'.
'QIAKJR}*JV]wRAI*J?}T]*RJcJI[\]3;U]Uq*PM[wV]W]WCT*DM*SJ'. 'ZP[Z'.
'PZa[\]UKVgogK9K*QJ[\]n[RI#*EH#IddR[Q[]T]T]T3o[dk*JE'. '[Z\U'.
'{T]*JPKTKK]*OJ[QIO[PIQIO[[gUKU\k*JE+J+J5R5AI*EJ00'. 'BCB*'.
'DMKKJIR[Q+*EJ0*EK';sub h{$\ = qw(% & # x)[int rand
4];map{printf "\e[$b;%dm",int(rand 6)+101-60* ($w
||0);system( "cls")if$w ;($A,$S)= ($_[1], $
_[0]);($M, #,)= split '}';for( $z=256
;$z>0; $z -=$S){$S*= $A;p #,} sleep$_
[2];while ($_[3]&&($ z+=$ S) <=256){
p#,}}("". "32}7D$j" ."}AG". "$u}OG"
."$s}WG" ."$t","" ."24}(" ."IJ$a"
."}1G$n" ."}CO$o" ."}GG$t" ."}QC"
."$h}" ."^G$e" ."})IG" ."$r",
"32}?" ."H$p}FG$e}QG$r". "}ZC"
."$l", "28}(LC" ."" ."".
"$h}:" ."J$a}EG". "$c"
."}M" ."C$k}ZG". "$e"
."}" ."dG$r","18" ."}("
."D;" ."$C" )}{h(16 ,1,1,0
);h(8, .98,0,0 );h(16 ,1,1,1)
;h(8.0 ,0.98,0, 1); redo}###
#written 060204 by
#liverpole #######
############
You can find out quite a bit about what people are currently doing with Perl by taking a look at the posts submitted to the Enlightened Perl Iron Man Challenge.
Personally, I'm currently using it to build the site for (yet another) AJAX-enabled, Twitterfied, etc., etc. social networking startup.
Web sites, data processing/extraction, system administration, task automation, even GUI programming. Mathematics, bioinformatics, chemistry, geology programs.
At my company we used to use Perl to run hundreds of RegEx's to transform random publisher files into SGML to make electronic books. Alas, those days are over now that we've updated our systems to XML books.
I use Perl for what it has been designed: a Practical way for Extracting useful information from raw data and presenting them in human-readable Reports. This is a very nice Language for this task.
Is there a Perl module that allows me to view diffs between actual and reference output of programs (or functions)? The test fails if there are differences.
Also, in case there are differences but the output is OK (because the functionality has changed) I want to be able to commit the actual output as future reference output.
Perl has excellent utilities for doing testing. The most commonly used module is probably Test::More, which provides all the infrastructure you're likely to need for writing regression tests. The prove utility provides an easy interface for running test suites and summarizing the results. The Test::Differences module (which can be used with Test::More) might be useful to you as well. It formats differences as side-by-side comparisons. As for committing the actual output as the new reference material, that will depend on how your code under test provides output and how you capture it. It should be easy if you write to files and then compare them. If that's the case you might want to use the Text::Diff module within your test suite.
As mentioned, Test::Differences is one of the standard ways of accomplishing this, but I needed to mention PerlUnit: please do not use this. It's "abandonware" and does not integrate with standard Perl testing tools. Thus, for all new test modules coming out, you would have to port their functionality if you wanted to use them. (If someone has picked up the maintenance of this abandoned module, drop me a line. I need to talk to them as I maintain core testing tools I'd like to help integrate with PerlUnit).
Disclaimer: while Id didn't write it, I currently maintain Test::Differences, so I might be biased.
I tend to use more of the Test::Simple and Test::More functionality. I looked at PerlUnit and it seems to provide much of the functionality which is already built into the standard libraries with the Test::Simple and Test::More libraries.
I question those of you who recommend the use of PerlUnit. It hasn't had a release in 3 years. If you really want xUnit-style testing, have a look at Test::Class, it does the same job, but in a more Perlish way. The fact that it's still maintained and has regular releases doesn't hurt either.
Just make sure that it makes sense for your project. Maybe good old Test::More is all you need (it usually is for me). I recommend reading the "Why you should [not] use Test::Class" sections in the docs.
The community standard workhorses are Test::Simple (for getting started with testing) and Test::More (for once you want more than Test::Simple can do for you). Both are built around the concept of expected versus actual output, and both will show you differences when they occur. The perldoc for these modules will get you on your way.
You might also want to check out the Perl QA wiki, and if you're really interested in perl testing, the perl-qa mailing list might be worth looking into -- though it's generally more about creation of testing systems for Perl than using those systems within the language.
Finally, using the module-starter tool (from Module::Starter) will give you a really nice "CPAN standard" layout for new work -- or for dropping existing code into -- including a readymade test harness setup.
For testing the output of a program, there is Test::Command. It allows to easily verify the stdout and stderr (and the exit value) of programs. E.g.:
use Test::Command tests => 3;
my $echo_test = Test::Command->new( cmd => 'echo out' );
$echo_test->exit_is_num(0, 'exit normally');
$echo_test->stdout_is_eq("out\n", 'echoes out');
$echo_test->stderr_unlike( qr/something went (wrong|bad)/, 'nothing went bad' )
The module also has a functional interface too, if it's more to your liking.