Lists sender and subject on all mails in mailbox. MIME::WordDecoder is used to parse heads as most mails often has ISO-8859-1 encoded parts. It should be save to test it on any mailbox as it dosn’t change or remove anything from the mailbox.
#!/usr/local/bin/perl -w use strict; use Mail::POP3Client; use MIME::WordDecoder; my ($serv, $usr, $pwd) = (@ARGV); # server, username and password as comandline parameters... my $wd = default MIME::WordDecoder; my $pop = new Mail::POP3Client( USER => $usr, PASSWORD => $pwd, HOST => $serv ); print "Found " .
This example connects to a LDAP server and makes a search for a name. The name was choosen by random (among those who returned an answer from the queried LDAP). The LDAP used in this example includes a binary certificate. To prevent this from trashing you terminal, it is not printed to the screen (binary field filtered in the attribute loop).
#!/usr/bin/perl -w use strict; use Net::LDAP; my $ldap = Net::LDAP->new('directory.
The following script will make a list of which folders exist in an IMAP account. The script requires you pass hostname, accountname and password on the commandline, but it should be quite easy to change as you like.
#!/usr/bin/perl -w use strict; use Mail::IMAPClient::BodyStructure; use Mail::IMAPClient; my ($serv, $usr, $pwd) = (@ARGV); # server, username and password as comandline parameters... my $imap = Mail::IMAPClient->new(Server=>$serv,User=>$usr,Password=>$pwd); my @folders = $imap->folders; foreach my $f (@folders) { print "$f is a folder with ", $imap->message\_count($f), " messages.
David HH has an interesting piece on “The false promise of template languages”. While neither Perl nor PHP may offer the same clean syntax in the code as Ruby can do, it does indeed raise a few interesting questions about how actually benefit from the templates and who does in the space between designers and developers. I do love some degree of separation between heavy duty code and the interface layer, and usually work with HTML::Template or Smarty – they work and the penalty for using a separation layer seems to be the smallest possible (at least in a balanced performance/ functionality view).
SQL is a common language implemented by most databases. While it’s a nice language it does lack some features available in some databases (which often differ from database to database). Some argue, that you shouldn’t go beyond the contrains and limitations in SQL because that removes your ability to switch to a different database. That’s just wrong (in my opinion). SQL usually allows you to do all the searches and CRUD operations you need, and by not going beyond the limitations posed by SQL you can switch your application to another database with an absolute minimum number of changes in your application - especially if you utilize the Perl DBI or the Pear DB (in PHP).