Perl: Can I use pattern matching to find certain lines in a log file

Question

I have a log file with this type of content:

Mon Nov 19 11:00:01 2012
Host: myserver
accurev-ent inuse: 629


Mon Nov 19 12:00:01 2012
Host: myserver
accurev-ent inuse: 629

Using Perl, I have figured out how to remove the empty lines and put the non-empty lines into an array. Now I'm trying to match the present month, date and year. I.e., I'm trying to grab all of the lines that have May, 21, and 2013 (this file is the product of a script that runs everyday and 24 times each day. I don't need the hh:mm:ss data.

I keep trying to pattern match this in the following vein:

foreach $prod (@prod)
{
  # Sun May 19 02:00:01 2013
  if ($prod =~ ((/Sun May 19/) && $prod =~(/2013$/)) )
  {
    print "Howdy! \n"; # just using to indicate success
  }
}  

Can I do this via pattern matching or should I try to split this and find the data match? By the way, once I find the match I need to put the line containing inuse into an array and find the largest number for the day.

Answer 1

#!/usr/bin/env perl
use strict;
use warnings;
use POSIX qw(strftime);

# The active regex looks for today's date
# The commented out regex looks for dates in the current month
# If you provide a suitable timestamp (seconds since the epoch),
# you can generate the pattern for an arbitrary date by changing
# time (a function call) to $timestamp.
my $pattern = strftime("%B %d \\d+:\\d+:\\d+ %Y", localtime(time));
# my $pattern = strftime("%B \\d+ \\d+:\\d+:\\d+ %Y", localtime(time));
# print "$pattern\n";
my $regex = qr/$pattern/;

# my @prod = <>;

foreach my $prod (@prod)
{
    # print "Check: $prod\n";
    if ($prod =~ $regex)
    {
        print "$prod\n";
    }
}

This uses strftime (from POSIX) to create a regex string with the current month and year in the correct places, and handles strings of digits where the day and time components should be. It then creates a quoted regex with qr//, and applies that to each entry in the @prod array. You can make the \d+ matches more rigid if you wish; whether it is worth doing so depends on the cost of an extraneous match. (One version of the current regex is more lenient than it could be, recognizing the 99th and 00th of May, and also May 20130, etc; they both allow invalid times through). All these are fixable by tweaking the regex without materially affecting the answer.