Perl@PolettiX

A few days ago a colleague asked me about using Perl for analysing some ASA firewall logs in order to spot how many public addresses are needed for NATting users towards the Internet. The basic regular expression to capture the bits of information that he needs is quite straightforward, but what was interesting is that the files he has to work on are gzipped, and he had already extracted a sample one to work on. I remembered that there is IO::Zlib and this is what I did:

for my $file (@ARGV) {
   eval {
      my $fh = _open($file);
      while (<$fh>) {
         my ($inside, $outside) = /Built\ dynamic\ translation\ from\ inside:(.*?)\ to\ outside:(.*?)/mxs
            or next;
         # use $inside and $outside
      }
      close $fh;
   } or warn "exception for '$file': $EVAL_ERROR";
}

sub _open {
   my ($file) = @_;
   my $fh;
   if ($file =~ /\.gz \z/mxs) {
      $fh = IO::Zlib->new();
      $fh->open($file, 'rb')
         or die "IO::Zlib complained: $OS_ERROR";
   }
   else {
      open $fh, '<', $file
         or die "open(): $OS_ERROR";
   }
   return $fh;
}

It worked pretty well so nothing to complain. Just before blogging about it, I paid a due visit to the documentation, and I discovered that I was more or less lucky: there are limitations in using the module, which basically boil down to $fh not being what you expect from a full fledged filehandle. But, at least, it should work out of the box if all you need is to read the file one line at a time.

The module isn't in the core distribution, but it's a common prerequisite so chances are that you already have it in your distro. It's a bit weird that it is known by corelist to have been included in 5.9.3:

IO::Zlib was first released with perl 5.009003

even though there is no trace of it in 5.10. Go figure. Anyway, it should be a bit more common to find than the alternative PerlIO::gzip, which would make the sub _open unneeded when substituted with this:

   open my $fh, '<:autopop', $file or die '...';

I wonder how much Perl IO layers are used out there.

I read about Perl6::Junction in an artile in blogs.perl.org and I was tickled. I quickly went on CPAN to see what the module was about beyond the post above, and saw two enthusiastic reviews by two bigs (at least this is what I consider both of them).

I have to say that I was a bit disappointed in seeing that they both talked about very clear documentation, while it seemed a bit too minimal for my taste. I do agree that the test suite is complete, anyway, and it's a useful source for examples too! The tests are indeed quite extensive, and there are also tests for something that made me curious, i.e.: "will it be possible to use junctions on both sides?". The answer turns out to be positive, and there are tests for those cases (see the T/join.t test file for details).

One funny thing in the module is that the following both apply:

my $is_true = (all(3, 4) == any(3, 4));
my $is_NOT_true = (any(3, 4) == all(3, 4));

It actually makes sense: the first says "do all elements in the {3, 4} set have something equal to them in the {3, 4} set?". Course they do, because 3 in the first set has 3 in the second, and 4 in the first set has 4 in the second. The second says "is any element in the {3, 4} equal to all the elements in {3, 4}?". Course there isn't, because 3 from the first set is equal to 3 in the second set, but fails to be equal to 4.

Hence, the (numeric) equality operator does not maintain the reflexive property here, and it seems just... weird, even though it makes perfectly sense.

After the previous post, I shipped the script and the related libraries to the recipient and slept as a baby. Just to discover that they didn't figure out how to use it properly!

The main issue is that geeks and technical people generally don't read the documentation. I admit, most of the times I don't do this as well. In this case, my good colleague saw a Perl script, made the too-simple-to-seem-true association between Perl and the Web and installed Apache! Well, as a matter of fact it is a web application, but I strived to make it self-contained and you end up with Apache?!?

Luck was that I was there some thirty minutes after to correct the problem and let Perl shine: "hey bro, it's a single program with an embedded web server!". That was the lucky part, anyway: the environment we're working into is particularly hostile, to the point that two machines in the very same network can't ping one another! Fortunately when I did use the program to make some tests the network connectivity was not that bad and we managed to do them.

Another thing that annoyed me a bit was that the script was not fully self-contained. Yes, I have to ship a hole tar.gz file... so I thought that it would be great to distribute a single script without anything more. One option is PAR, of course, but I always regretted to use it because you basically have to compile for a target architecture (at least in my understanding). In case of Pure-Perl stuff this does not make me happy.

Some time ago I had a similar problem that I solved with a script to bundle Pure-Perl modules inside a script. I put it in repository in repo.org.cz, for anyone to have a good laugh.

Wow, I'm very pleased to see the new face of Perl.org. I have to thank Paul Fenwick for the hint!

Divertito mi sono divertito! Rivedere gli amici perlisti, conoscerne di nuovi... Ho notato una cosa, però: la gente sembrava veramente poca quando si stava nella sala grande!

Le presentazioni che ho fatto sono su SlideShare: