Three Blinding Perl Tips, See How They Execute

Sep 17, 2009

I've got a lot of half written posts that I still need to complete, but I don't want to let this blog stagnate. Quick! Time for an n things list - Three random Perl things that I've been using a lot recently:

Default Prompts

If you install Term::ReadLine::Perl you can provide defaults for interactive prompts in your program

my $term = Term::ReadLine->new('report');
my $filename = $term->readline(
   "file to write output to? ",
   "$ENV{HOME}/report-".DateTime->now->ymd.".csv"
);

When this executes this code creates a line in your terminal that has a default value already filled in for you to edit:

file to write output to? /Users/mark/report-2009-09-16.csv

Controlling Where lwp-request Sends Its Requests

The command line utility lwp-request, which is a handy Perl utility that ships with LWP that allows you to download webpages from the command line, can take proxy settings from the environment variables you pass to it.

bash$ http_proxy=http://127.0.0.1 lwp-request http://www.mywebsite.com

This is really useful for development: You can set your test apache running on your local machine / virtual machine / dev box up to answer on the same virtual host name as your live domain and, via the proxy settings, have lwp-request send requests there rather than to the real live machine whose DNS the domain name points to. This is also really useful for debugging reverse proxies in live - you can choose exactly which machine in your proxy chain to send to, bypassing the nginx / lighttpd / varnish front proxy machine and talking directly to the backend machine if you wish.

The "Just Show Me The Data" Incarnation for DBI

Most of the time I don't use DBI directly - I use an object relational mapper like DBIx-Class. But sometimes I'll get handed a chunk of SQL from our DBA and I just want to write a wrapper script to run that SQL and do something simple with it. DBI is very flexible, and the documentation talks at length about things like caching parsed queries, reading data in from the database row by row, efficency of data structures, etc, etc. What it's not very clear about, however, is how to ignore all of that and just get all your data from executing some SQL in the easiest possible format to manipulate. The magic incarnation looks like this:

    my $dbh = DBI->connect(
      "DBI:mysql:hostname=127.0.0.1;database=foo",
      $username, 
      $password,
      { RaiseError => 1 },
    );

    my $rows = $dbh->selectall_arrayref( <<'SQL',{ Slice => {} }, "flintstone");
      SELECT *
        FROM characters
       WHERE last_name = ?
    SQL

This gives you a reference to an array, with each element in this array representing one row returned from the database as a hashref keyed by field name. This is really easy to process:

    foreach my $row (@{ $rows }) {
      say " * $row->{first_name} $row->{last_name}";
    }

If there's any problem at all DBI will raise an exception, so you don't need to worry about writing lots of error checking code.