Perl 5.10 added rudimentary grammar support in its regular expressions. You could define many subpatterns directly in your pattern, use them to define larger subpatterns, and, finally, when you have everything in place, let Perl do the work.

There are other ways, some more powerful, that let you do the same thing. This Item is not about those, however, but you can read about Regex::Grammars, Parse::RecDescent on your own. Also, you’re not going to get much of a recommendation of which one you should use for your task. We don’t know your situation.

To understand this new syntax, you have to study it from the ground up. It’s not simple, and the terse documentation in perlre doesn’t do much to help.

Referencing a subpattern

The first part you need is the ability to call a named part of the pattern (to label a subpattern, see Item 31. Use named captures to label matches). To re-match a labeled subpattern, you use:

(?&NAME)

You can use that syntax to rerun a subpattern later:

use v5.10;

my $pattern = qr/
	(?<cat>Buster|Mimi)
	\s+
	(?&cat)
	/x;

foreach ( 'Buster Mimi', 'Mimi Buster', 'Buster', 'Buster Buster' ) {
	say "$_ ", m/$pattern/p ? "matched" : 'nope!';
	}

The labeled subpattern has an alternation where either cat name can match. When you reference it again, you re-run the alternation and you can match either cat name again:

Buster Mimi matched
Mimi Buster matched
Buster nope!
Buster Buster matched

This is not that same thing as matching the same text a labeled capture group already matched. That’s the \k<NAME>:

\k<NAME>

This pattern is a different beast. Whichever cat name matches first also has to match second:

use v5.10;

my $pattern = qr/
	(?<cat>Buster|Mimi)
	\s+
	\k<cat>
	/x;

foreach ( 'Buster Mimi', 'Mimi Buster', 'Buster', 'Buster Buster' ) {
	say "$_ ", m/$pattern/p ? "matched" : 'nope!';
	}

Now only one of the strings matches because only one string repeats a cat’s name:

Buster Mimi nope!
Mimi Buster nope!
Buster nope!
Buster Buster matched

Although you won’t see it here, the (?&NAME) syntax is the trick to matching a recursive pattern since the reference can appear inside the pattern it references.

Conditional match

The second building block you need starts with a conditional submatch:

(?(condition)yes-pattern|no-pattern)

That condition can be many things, most of which won’t appear in this Item. Although you see the | character, but this isn’t an alteration. It’s like an alternation because the | separates distinct subpatterns, but unlike an alternation because this will only ever try one of the subpatterns and you only get two subpatterns.

The simplest condition is just an ordinal number, which is true only if that capture group matched. Here’s a pattern that has two capture groups:

use v5.10;

my $pattern = qr/
	(?:           # parens for grouping
		(B)     # $1
		|         # alternation
		(M)     # $2
	)
	(?(1)uster|imi) # conditional match
	/x;

foreach ( qw(Mimi Buster Muster Bimi Roscoe) ) {
	say "$_ ", m/$pattern/p ? "matched ${^MATCH}" : 'nope!';
	}

In this pattern, if the (B) matches, the conditional uses uster from the conditional. Otherwise, it uses imi. However, the only thing that can match besides a (B) is the other part of the alteration, the (M). The output shows that only Mimi or Buster matches:

Mimi matched Mimi
Buster matched Buster
Muster nope!
Bimi nope!
Roscoe nope!

You get the same results if you use (2) as the condition and re-arrange the order of the patterns:

my $pattern = qr/
	(?:(B)|(M))
	(?(2)imi|uster)
	/x;

Putting it together

The condition can also be the literal (DEFINE). In that case, Perl only allows a yes-branch. And, as its condition implies, it merely defines the patterns and does not execute them.

This means that you can create and label the subpatterns that you need, but not actually assert that any of them match the string. The definitions are just there. This pattern defines and labels three subpatterns then uses none of them:

use v5.10;

my $pattern = qr/
	(?(DEFINE)
		(?<cat>Buster)
		(?<dog>Addie)
		(?<bird>Poppy)
	)
	Mimi
	/x;

foreach ( 'Buster Mimi', 'Roscoe', 'Buster', 'Mimi' ) {
	say "$_ ", m/$pattern/ ? "matched" : 'nope!';
	}

It’s as if the DEFINE bit is not even there:

Buster Mimi matched
Roscoe nope!
Buster nope!
Mimi matched

Outside the (DEFINE), you can reference any of the subpatterns that you created:

use v5.10;

my $pattern = qr/
	(?(DEFINE)
		(?<cat>Buster)
		(?<dog>Addie)
		(?<bird>Poppy)
	)
	(?&cat)
	/x;

foreach ( 'Buster Mimi', 'Roscoe', 'Buster', 'Mimi' ) {
	say "$_ ", m/$pattern/ ? "matched" : 'nope!';
	}

Now Buster matches because you reference that defined subpattern:

Buster Mimi matched
Roscoe nope!
Buster matched
Mimi nope!

Now it’s time for the grammar. Inside the (DEFINE), you can reference subpatterns you haven’t defined yet, and your subpatterns can get arbitrarily complex:

use v5.10;

my $pattern = qr/
	(?(DEFINE)
		(?<male> Buster | Roscoe )
		(?<female> Mimi | Juliet )
		(?<cat> (?&male) | (?&female) )
		(?<dog>Addie)
		(?<bird>Poppy)
	)
	(?&cat)
	/x;

foreach ( 'Addie', 'Roscoe', 'Buster', 'Mimi' ) {
	say "$_ ", m/$pattern/ ? "matched" : 'nope!';
	}

Even though the cat names are in two different subpatterns, the cat subpattern unifies them so all the cat names match:

Addie nope!
Roscoe matched
Buster matched
Mimi matched

You should now be able to understand this regular expression from Tom Christainsen (appearing Stackoverflow). You might have to pick it apart, but you know how all the parts fit together to match the Internet Message Format defined in RFC 5322:

$rfc5322 = qr{

   (?(DEFINE)

     (?<address>         (?&mailbox) | (?&group))
     (?<mailbox>         (?&name_addr) | (?&addr_spec))
     (?<name_addr>       (?&display_name)? (?&angle_addr))
     (?<angle_addr>      (?&CFWS)? < (?&addr_spec) > (?&CFWS)?)
     (?<group>           (?&display_name) : (?:(?&mailbox_list) | (?&CFWS))? ; (?&CFWS)?)
     (?<display_name>    (?&phrase))
     (?<mailbox_list>    (?&mailbox) (?: , (?&mailbox))*)

     (?<addr_spec>       (?&local_part) \@ (?&domain))
     (?<local_part>      (?&dot_atom) | (?&quoted_string))
     (?<domain>          (?&dot_atom) | (?&domain_literal))
     (?<domain_literal>  (?&CFWS)? \[ (?: (?&FWS)? (?&dcontent))* (?&FWS)?
                                   \] (?&CFWS)?)
     (?<dcontent>        (?&dtext) | (?&quoted_pair))
     (?<dtext>           (?&NO_WS_CTL) | [\x21-\x5a\x5e-\x7e])

     (?<atext>           (?&ALPHA) | (?&DIGIT) | [!#\$%&'*+-/=?^_`{|}~])
     (?<atom>            (?&CFWS)? (?&atext)+ (?&CFWS)?)
     (?<dot_atom>        (?&CFWS)? (?&dot_atom_text) (?&CFWS)?)
     (?<dot_atom_text>   (?&atext)+ (?: \. (?&atext)+)*)

     (?<text>            [\x01-\x09\x0b\x0c\x0e-\x7f])
     (?<quoted_pair>     \\ (?&text))

     (?<qtext>           (?&NO_WS_CTL) | [\x21\x23-\x5b\x5d-\x7e])
     (?<qcontent>        (?&qtext) | (?&quoted_pair))
     (?<quoted_string>   (?&CFWS)? (?&DQUOTE) (?:(?&FWS)? (?&qcontent))*
                          (?&FWS)? (?&DQUOTE) (?&CFWS)?)

     (?<word>            (?&atom) | (?&quoted_string))
     (?<phrase>          (?&word)+)

     # Folding white space
     (?<FWS>             (?: (?&WSP)* (?&CRLF))? (?&WSP)+)
     (?<ctext>           (?&NO_WS_CTL) | [\x21-\x27\x2a-\x5b\x5d-\x7e])
     (?<ccontent>        (?&ctext) | (?&quoted_pair) | (?&comment))
     (?<comment>         \( (?: (?&FWS)? (?&ccontent))* (?&FWS)? \) )
     (?<CFWS>            (?: (?&FWS)? (?&comment))*
                         (?: (?:(?&FWS)? (?&comment)) | (?&FWS)))

     # No whitespace control
     (?<NO_WS_CTL>       [\x01-\x08\x0b\x0c\x0e-\x1f\x7f])

     (?<ALPHA>           [A-Za-z])
     (?<DIGIT>           [0-9])
     (?<CRLF>            \x0d \x0a)
     (?<DQUOTE>          ")
     (?<WSP>             [\x20\x09])
   )

   (?&address)

}x;

If that’s not clever enough for you, try Tom’s use of (DEFINE) to properly parse HTML.

Things to remember

• You can reference a named subpattern with (?&NAME)
• You can choose a subpattern with a condition (?(condition)yes-pattern|no-pattern)
• You can define and label subpatterns for later use with (DEFINE)

Single character separators are easy

use v5.10;

my @letters = split /:/, 'a:b:c:d:e';
say "@letters";

The list comes out just as you expect:

a b c d e

Even multiple or variable width patterns are fine:

use v5.10;

my @cats = split /\s+/, 'Buster
	Mimi     Roscoe';
say "@cats";

The list comes out just as you expect:

Buster Mimi Roscoe

It gets more tricky when you have balanced delimiters, when there’s something that marks the start and the end of a value. The problem is that there is something in front of the first element and something after the last element. You can’t split on the pattern of characters between the values because you don’t remove everything:

use v5.10;

my @cats = split /\s+/, '<Buster><Mimi><Roscoe>';
say "@cats";

The first and last delimiter characters are still attached to their values:

<Buster Mimi Roscoe>

You might be tempted to live with that and process those values after the split:

use v5.10;

my @cats = split /></, '<Buster><Mimi><Roscoe>';
$cats[0] =~ s/<//;
$cats[-1] =~ s/>//;
say "@cats";

Some people might be satisfied with that, and it does work, but it’s much better to remove the special cases. If you limit yourself to matching just the character that you want to remove, you’re a bit limited. One problem is the empty leading field that you get if you try to match the first delimiter character:

use v5.10;

my @cats = split /><|\A<|>\z/, '';

say "@cats";

There’s a space at the beginning of the output because there’s an empty leading field, but the list at least doesn’t have any of the delimiter characters:

 Buster Mimi Roscoe

To fix this, you still need to handle the leading field, perhaps by shifting it off. Again, this works, even if it’s unsightly:

use v5.10;

my @cats = split /><|\A<|>\z/, '';
shift @cats;

say "@cats";

The special processing isn’t as bad, but you have to remember to handle that one element.

Instead of matching characters, you can use lookarounds to split on the the middle of the balanced delimiter by using a zero-width assertion. The lookarounds match a condition in the string but do not consume any characters. These are conditions in the string, not characters to match.

If you use a lookbehind next to a lookahead, you can split on the position in the string where both conditions match. You want to match in the middle of a >< so the > ends up with the preceding element and the < stays with the succeeding element.

The positive lookbehind has the general form (?>=PATTERN). That pattern, which must be fixed-width, must match before the position. In this case, you want to match a > before the position, so the assertion is (?>=>).

The positive lookahead is almost the same thing, with the form (?=PATTERN). You want to match a < after the position, so your assertion is (?=<).

Putting them together, the lookbehind next to the lookahead, splits the values:

use v5.10;

my @cats = split /(?<=>)(?=<)/, '';

say "@cats";

The output list still has the delimiter characters, but now each element needs the same processing, so there are no special cases:

<Buster> <Mimi> <Roscoe>

Once you have the values in their own elements, you can remove the delimiters:

use v5.14;

my @cats =
	map { s/\A<|>\z//rg }    # return the modified value
	split /(?<=>)(?=<)/,
	'';

say "@cats";

That might seem a bit silly, but we’re only using a simple example to illustrate the point.

Consider a slightly more complicated case, where the fields are quoted, but then separated by commas. Unless your learning to re-invent the wheel (a valid exercise to sharpen your skills), you should probably use a module (Item 115. Don’t use regular expressions for comma-separated values). For this example, you’ll do it yourself:

use v5.10;

my @cats =
	split /(?<="),(?=")/,
	'"Buster","Mimi","Roscoe"';

say "@cats";

This removes the commas, as long as they are between quotes. However, you leave the quotes in place so you don't treat the first and last values specially:

"Buster" "Mimi" "Roscoe"

To get rid of the quotes, you process each item in the same way:

use v5.14;

my @cats =
	map { s/\A"|"\z//rg }       # return the modified value
	split /(?<="),(?=")/,
	'"Buster","Mimi","Roscoe"';

say "@cats";

You might try to construct a more complicated regular expression to also remove the quotes, but that's going to be harder to read and maintain than doing it in two simple steps.

Things to remember

• You don't have to remove delimiters in one step
• You can use a lookbehind next to a lookahead to specify a position in a string

For a simple example, you can split an entry from /etc/password (although getpw* functions will do that for you):

root:*:0:0:System Administrator:/var/root:/bin/sh

The colons separate the fields, so you split on a colon:

my @fields = split /:/, $passwd_line;

That works just fine because the separator is a single character, that character is the same between each field, and the separator character doesn’t appear in any of the data.

A slightly more tricky example has a character from the separator also show up in the data. Consider comma-separated values which also allows a comma in the data. If you really have to do this, you would use a module (Item 115. Don’t use regular expressions for comma-separated values). However, this is a good task to illustrate some of the tricks in this Item. You might see these data stored in many ways. You are likely to see all the fields quoted if any one of them has the comma:

"Buster","Roscoe, Cat","Mimi"

You can split on ",", which separates all the fields:

my $string = q("Buster","Roscoe, Cat","Mimi");

my @fields = split /","/, $string;

$" = "\n";
print "@fields\n";

However, the first and last fields have remnants of the quoting:

"Buster
Roscoe, Cat
Mimi"

In this case, the simple split failed because it only removes text between the fields and doesn’t care at all about text at the beginning of the string or the end of the string.

You might think that you can make special cases to handle the beginning and end of the string bits. Creating special cases is almost always what you want to avoid: they make the code more complicated and they make you think about more than you really need to think about. Still, you can do that with alternations in the pattern:

my $string = q("Buster","Roscoe, Cat","Mimi");

my @fields = split /\A"|","|"\z/, $string;

$" = "\n";
print "@fields\n";

And, it doesn’t work. The split maintains leading open fields, so we get an extra field at the start:

Buster
Roscoe, Cat
Mimi

You could handle that by removing the first element, but that’s more duct tape and spit over the other kludge. Not only do you have two special cases in the pattern, but you have a special case in the output.

You don’t have to remove the quotes right away though. You can reduce all the special cases by not matching the quote characters in the split pattern. You can use a lookaround to find the commas surrounded by quotes:

my $string = q("Buster","Roscoe, Cat","Mimi");

my @fields = split /(?<="),(?=")/, $string;

$" = "\n";
print "@fields\n";

The positive lookbehind, (?<=...), is a zero-width assertion. It matches a pattern that exists (hence positive) but doesn't consume the characters it matches. You already know about other zero-width assertions, such as \b and ^. These merely match a condition in the string before the pattern. The positive lookahead, (?<=...), is the same thing, but looks forward of the pattern.

Now all of the fields retain their quotes because the lookarounds do not consume the characters they match, even though they assert those characters must be there:

"Buster"
"Roscoe, Cat"
"Mimi"

You can easily strip off the quotes, handling every element returned by split in the same way:

use v5.14;
my $string = q("Buster","Roscoe, Cat","Mimi");

my @fields =
	map { s/\A"|"\Z//gr }
	split /(?<="),(?=")/, $string;

$" = "\n";
print "@fields\n";

The pattern has no special cases, and the output from split has no special cases. Eliminating special cases reduces the number of things you have to remember and the reduces the likelihood that you'll mess up one of the cases.

Buster
Roscoe, Cat
Mimi

What if the separator where even more complex, with a literal quote mark inside the data? If you can do that, you can imagine a quote character next to a comma in the field:

"Buster","Roscoe "","" Cat","Mimi"

Now you want to split on a comma with quotes around it, but only if it doesn't have two consecutive quotes on either side. You can combine the positive lookarounds with negative lookarounds. The negative versions act the same, but assert that the condition cannot match, just like a \B asserts that the position is not a word boundary:

use v5.14;
my $string = q("Buster","Roscoe "","" Cat","Mimi");

my @fields =
	map { s/"(?=")//gr }
	map { s/\A"|"\z//gr }
	split /(?<!"")(?<="),(?=")(?!"")/, $string;

$" = "\n";
print "@fields\n";

In processing the "", you use another positive lookahead to unescape the doubled double quote character:

Buster
Roscoe "," Cat
Mimi

As a final example, instead of quoted fields, you might see the non-separator comma as an escaped character:

Buster,Roscoe\, Cat,Mimi

In this case, you only want to split on a comma that does not have an escape character before it. You can't use a positive lookbehind because you don't want to match characters before the comma. Instead, you want a negative lookbehind because you want to assert that there are characters that can't appear before the comma. Instead of a =, you use a !:

use v5.14;
my $string = q(Buster,Roscoe\\, Cat,Mimi);

my @fields =
	map { s/\\(?=,)//gr }
	split /(?<!\\),/, $string;

$" = "\n";
print "@fields\n";

Again, you use another positive lookahead, (?=,), in the s/// so you substitution pattern does not match the character that you don't want to replace. Otherwise, you'd have to type the comma twice:

s/\\,/,/gr

You can go even further with these examples, creating much more ugly and complex examples with additional levels of quoting. This should naturally lead you to believe that regular expressions aren't the best tool for this (or at least a single regular expression).

Things to remember

• If you really have to parse comma-separated values, use a module instead of writing your own patterns
• Lookarounds assert a condition in the string without consuming any characters
• The positive lookarounds assert their patterns must match
• The negative lookarounds assert their pattern must not match
• Use the lookarounds to eliminate special cases in complex split patterns

You can use any modifier that affects the pattern, but not the modifiers that affect the operator (see Know the difference between regex and match operator flags). Try an example with an easier modifier. The /i modifier makes the pattern case insensitive. Instead of adding that for all of your match operations, you use the re pragma’s flags mode. In this example, you use the Test::More module to experiment with new ideas.

First, write some tests that you expect to fail. Since the pattern is all lowercase, but the target string has an uppercase letter, these should fail:

use 5.014;
use Test::More;

like( 'Buster', qr/buster/, 'Buster matches with qr//' );
ok( 'Buster' =~ m/buster/, 'Buster matches with m//' );
done_testing();

And they do fail. That’s a good thing, because you want to magically make them pass by adding a default modifier:

not ok 1 - Buster matches with case insensitivity
not ok 2 - Buster matches with m//
1..2
#   Failed test 'Buster matches with case insensitivity'
#                   'Buster'
#     doesn't match '(?^u:buster)'
#   Failed test 'Buster matches with m//'
# Looks like you failed 2 tests of 2.

Now, add the default modifiers. You add those through the import list for the re module. The list of modifiers starts with a slash to distinguish it from other imports. To make the /i the default, that’s exactly what you import:

use 5.014;
use Test::More;

use re '/i';
like( 'Buster', qr/buster/, 'Buster matches with case insensitivity' );
ok( 'Buster' =~ m/buster/, 'Buster matches with m//' );

done_testing();

Now the tests pass because they are case insensitive:

ok 1 - Buster matches with case insensitivity
ok 2 - Buster matches with m//
1..2

These default modifiers are only lexically scoped, and that’s how you should use them. You don’t want to change more than you intend, and the next programmer who comes along might not realize that you set the default modifiers at the top of the file. Try it with a lexical scope to check that it’s limited to that scope (see Know what creates a scope):

use 5.014;
use Test::More;

SCOPE: {
	use re '/i';
	like( 'Buster', qr/buster/, 'Buster matches with case insensitivity' );
	ok( 'Buster' =~ m/buster/, 'Buster matches with m//' );
	outside_scope();
	}

sub outside_scope {
	unlike( 'Buster', qr/buster/, 'Buster does not match with case insensitivity' );
	ok( !( 'Buster' =~ m/buster/ ), 'Buster does not match with m//' );
	}

done_testing();

Now that you see that the default modifier is limited to the lexical scope.

ok 1 - Buster matches with case insensitivity
ok 2 - Buster matches with m//
ok 3 - Buster does not match with case insensitivity
ok 4 - Buster does not match with m//
1..4

So far, you’ve used only one modifier as the default, but you can stack them just like you would with qr// or m// or s///. Suppose you want to turn on both /i and /s at the same time so you get case insensitivity and let the . match a newline:

use 5.014;
use Test::More;

use re '/is';
like( "Bu\nter", qr/bu.ter/, 'Bu\\nter matches with case insensitivity' );
ok( 'Buster' =~ m/bu.ter/, 'Buster matches with m//' );

done_testing();

Both of those work their magic as default values:

ok 1 - Bu\nter matches with case insensitivity
ok 2 - Buster matches with m//
1..2

You don’t have to stack them, though. You can specify them separately and it works just as well, although each group must start with a /:

use re '/i', '/s';

use re qw(/i /s);

Turn off default modifiers

Once turned on, these modifiers apply to all the patterns in the pragma’s scope, but if you don’t want an enabled modifier in a pattern. Suppose, for instance, that one part of the pattern absolutely should not be case insensitive. You can (?^:) sequence to turn off modifiers for a subpattern:

use 5.014;
use Test::More;
use re '/i';

foreach my $string ( qw(Buster bUSTER buster BuStEr) ) {
	say "$string matches" if  $string =~ /(?^:B)uster/;
	}

The output shows that only the strings starting with an uppercase B match because the (?^:B) portion turns off all modifiers for that subpattern. You should consider using (?^:) if you are also going to have default flags.

Things to remember

• Set default regular expression modifiers with the re pragma.
• You can only use modifiers that apply to the pattern, not the operator.
• You can stack multiple modifiers in a single import string, such as /is.
• Turn off modifiers for a subpattern with (?^:).

Suppose you want to find some dates inside a big string. The problem with dates is that there are some many ways to write them, and even if you can come up with a pattern to get the structure right, can you handle the different locales and languages that use different words to refer to the same day or month?

In Item 42. Don’t reinvent the regex, you saw the Regexp::Common module. It creates the regular expressions that many people often get wrong because they miss some subtle part of the pattern.

Regexp::Common::time‘s date handling is quite amazing though. It’s a plugin, so you need to install it separately. Instead of specifying a regular expression, you can use the -pat option to specify the structure of the date, using a string much like that for strftime, although with some regular expression bits added. From the semi-pattern, it constructs a much more complicated pattern that does the right thing. Since the module gives you a regex object, you can print it to see the pattern:

In this example, you extract the

use Regexp::Common qw(time);

my @lines = `ls -l`;

# May  3  2010
# Jan 17 18:21
$date_re = $RE{time}{strftime}{
	-pat => '%b\s+%_d\s+(?:%Y|%_H:%M)'
	};

print "Pattern is------\n$date_re\n-------\n";

This pattern reflects the national representation for the en_US locale:

Pattern is------
(?=[SAFOJNMD])(?>Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\s+(?:0[1-9]|[12]\d|3[01]|(?<!\d)[1-9])\s+(?:\d{4}|(?:(?=\d)(?:[01]\d|2[0123]|(?<!\d)\d)):(?:[0-5]\d))
-------

You can change your locale, in this case, to tr_TR for Turkish, to get a different pattern that has the same structure, although I don’t know if the Turks write their dates like this:

Pattern is------
(?=[AOTNKEHM\Å])(?>Oca|\Å\žub|Mar|Nis|May|Haz|Tem|A\Ä\Ÿu|Eyl|Eki|Kas|Ara)\s+(?:0[1-9]|[12]\d|3[01]|(?<!\d)[1-9])\s+(?:\d{4}|(?:(?=\d)(?:[01]\d|2[0123]|(?<!\d)\d)):(?:[0-5]\d))
-------

You can now use this pattern to match dates in text. Here’s a program that takes in a line and puts ^ characters under the parts it thinks are dates:

use Regexp::Common qw(time);

my @lines = `ls -l`;

# May  3  2010
# Jan 17 18:21
$date_re = $RE{time}{strftime}{
	-pat => '%b\s+%_d\s+(?:%Y|%_H:%M)'
	};

while( defined( my $line = <> ) {
	next unless $line =~ /$date_re/;
	my $start = $-[0];
	my $stop  = $+[0];

	my $underline = ( ' ' x $-[0] ) . ( '^' x ($stop - $start) );

	print $line;
	print $underline, "\n\n";
	}

You can test this by piping some output into this program. Here’s an extract of output from the Unix ls command. Notice that the first date has a time instead of a year, but you still find it:

$ ls -l /usr/local/perls/perl-5.10.1/lib/site_perl/5.10.1 | perl date_finder.pl
drwxr-xr-x   4 brian  wheel    136 Dec  9 01:58 Acme
                                   ^^^^^^^^^^^^

-r--r--r--   1 brian  wheel  32517 Jul  6  2007 AppConfig.pm
                                   ^^^^^^^^^^^^

-r--r--r--   1 brian  wheel  54725 Jul 19  2007 Expect.pm
                                   ^^^^^^^^^^^^

-r--r--r--   1 brian  wheel  43735 Jul 19  2007 Expect.pod
                                   ^^^^^^^^^^^^

drwxr-xr-x   3 brian  wheel    102 May 16  2010 ExtUtils
                                   ^^^^^^^^^^^^

drwxr-xr-x   3 brian  wheel    102 Jun 17  2010 local
                                   ^^^^^^^^^^^^

-r--r--r--   1 brian  wheel   9137 Jun 15  2009 lwpcook.pod
                                   ^^^^^^^^^^^^

-r--r--r--   1 brian  wheel  25447 Jun 15  2009 lwptut.pod
                                   ^^^^^^^^^^^^

drwxr-xr-x   4 brian  wheel    136 May 28  2010 namespace
                                   ^^^^^^^^^^^^

-r--r--r--   1 brian  wheel   1931 Sep 22  2009 oose.pm
                                   ^^^^^^^^^^^^

Notice that this would be hard to do with split if you run into filenames that have spaces. You can’t depend on fixed column widths because the file sizes can move things around. It turns out to be pretty annoying.