How many captures will a particular pattern produce? Can you tell just by looking at the pattern? How much does the particular string matter? How many capture groups are in this pattern:

(Buster)|(Mimi)|(Ella)

There are three capture groups. Only one of them is going to capture because each group is in a different branch of the alternation. What capture variables will that pattern set?

No matter which string you match against this pattern, you’ll also set at least three of the capture variables, and two of those will be undefined.

Perl 5.10 introduces the branch reset pattern, (?|alternation). You use that so that Perl numbers the capture buffers from the same starting point for each branch in the alternation. Instead of creating three capture buffers in your alternation, you can create just one buffer for this pattern:

(?|(Buster)|(Mimi)|(Ella))

The three capture groups in this pattern populate the same buffer:

This is more important when the alternation is in the middle of a larger pattern and there are additional capture groups after the alternation:

(?|(Buster)|(Mimi)|(Ella))(Ginger)

That’s a bit easier to read with extended patterns (Item 37: Make regular expressions readable):

(?|             # $1
	(Buster) |
	(Mimi)   |
	(Ella)
)
(               # $2
	Ginger
)

No matter how many branches you add to the alternation, the group for Ginger is always $2:

(?|             # $1
	(Buster) |
	(Mimi)   |
	(Ella)   |
	(Roscoe)
)
(               # $2
	Ginger
)

That doesn’t mean that the numbering after the alternation is always the same though. Not every branch must have the same number of captures, but the pattern reset grouping always takes up the number of buffers in the branch with the most capture groups even if that’s not the branch that matches. Consider this pattern where one of the branches has two capture groups:

(?|
	(Buster)       |  # $1, $2 is undef
	(Mimi)(Roscoe) |  # $1, $2
	(Ella)            # $1, $2 is undef
)
(                     # $3
	Ginger
)

The $1 variable is always the first capture group of whichever branch matched:

The branch reset can cause problems with named captures (Item 31: Use named captures to label matches), which are really just aliases the the numbered captured variables. Labeling each capture group doesn’t do what you might expect:

(?|
	(?<cat1>Buster)              |  # $1, $2 is undef
	(?<cat2>Mimi)(?<cat3>Roscoe) |  # $1, $2
	(?<cat4>Ella)                   # $1, $2 is undef
)
(?<cat5>
	Ginger
)

Each label is just an alias to its numbered capture variable:

The labels don’t apply to the groups you think they do:

You should probably use the same labels in each branch and order them the same so you get the results that you expect:

(?|
	(?<cat1>Buster)              |  # $1, $2 is undef
	(?<cat1>Mimi)(?<cat2>Roscoe) |  # $1, $2
	(?<cat1>Ella)                   # $1, $2 is undef
)
(?<cat3>
	Ginger
)

Things to remember

• Perl numbers capture groups by counting the literal order of left parentheses
• Every capture group in an alternation creates a capture buffer
• The pattern reset grouping, (?|...) restarts the buffer numbering for each branch of the alternation
• Label captures in alternations with the same labels in the same order

A statement modifier puts the conditional expression at the end of the statement (see perlsyn). You’ve probably already used many of these:

print "It's too darned hot!\n" if $city eq 'Baltimore';
print "I'm this far!\n" unless $Quiet;
print "An element is $_.\n" foreach @array;
print "Found cat at @{[pos]}\n" while /cat/g;
do { $count++; $i_am_bored = int rand 2 } until $i_am_bored;

In Perl 5.10, you have to put the when first, put parentheses around the conditional expression, and follow it with a block:

use 5.012;

my %microchips = (
	  'Mimi'   => 123,
	  'Buster' => undef,
	  'Roscoe' => 345,
	);
my @array = ( 5 .. 7 );

foreach ( 1 .. 10, qw(Mimi Buster) ) {
	when( @array )      { say "$_: in array" }
	when( %microchips ) { say "$_: in hash"  }
	}

Perl 5.12 allows you to use the when as a statement modifier instead, which means that you can put the when after the expression that you want to run:

use 5.012;

...;

foreach ( 1 .. 10, qw(Mimi Buster) ) {
	say "$_: in array" when( @array );
	say "$_: in hash"  when( %microchips );
	}

Just like you can with the other statement modifiers, you can omit the parentheses around the condition:

use 5.012;

...;

foreach ( 1 .. 10, qw(Mimi Buster) ) {
	say "$_: in array" when @array;
	say "$_: in hash"  when %microchips;
	}

As a statement modifier, the expression before the when has an implicit break when you use it with given or an implicit next when you use it with foreach. That is, once a when condition evaluates to true, Perl doesn’t continue with the rest of the block.

The foreach case actually looks like this:

use 5.012;

...;

foreach ( 1 .. 10, qw(Mimi Buster) ) {
	do { say "$_: in array"; next } when @array;
	do { say "$_: in hash";  next } when %microchips;
	}

And the given case actually looks like:

use 5.012;

...;

given ( $cat ) {
	do { say "$_: in array"; break } when @array;
	do { say "$_: in hash";  break } when %microchips;
	}

You’re still supposed to use when inside a topicalizer (e.g. foreach or given). You might be tempted to use it more liberally so you can take advantage of its implicit smart matching anywhere that you like. A curious and perhaps unintended parsing makes it a runtime error instead of a compilation error:

use 5.012;

my %microchips = (
	  'Mimi'   => 123,
	  'Buster' => undef,
	  'Roscoe' => 345,
	);

while( <STDIN> ) {
	chomp;
	# this works (without a warning) as long as the value in $_
	# is not a hash key
	say "Found cat with id [$microchips{$_}]" when %microchips;
	}

The while isn’t a topicalizer, even though in this particular idiom it sets $_ for you. You get the output along with a warning:

$ perl5.12.1 no-topicalizer.pl
Buster
Found cat with id []
Can't use when() outside a topicalizer at test line 11, <STDIN> line 1.

However, you don’t get a fatal error when the condition is false, which is probably another bug (filed as RT #77510). There’s no fatal error, no warning message, and the output shows that Perl kept going:

Ella
Mimi
Found cat with id 123
Can't use when() outside a topicalizer at test line 11, <STDIN> line 2.

Just because it it does just what you think it should do then dies telling you it doesn’t do that, don’t think you should do it. You could use eval to catch the fatal error, but that’s a kludge that will only work until the Perl developers fix the problem. Besides, if you are going to go that far, it’s just as easy to make the smart match explicit with an if statement modifier (and that is even backward compatible with 5.10):

use 5.010;

my %microchips = (
	  'Mimi'   => 123,
	  'Buster' => undef,
	  'Roscoe' => 345,
	);

while( <STDIN> ) {
	chomp;
	say "Found cat with id $microchips{$_}" if $_ ~~ %microchips;
	}

The only question now is how long you will be able to use this before your Perl::Critic policies update to forbid it, whether inside or outside of a topicalizer. Use it while you can: time is running out.

Some things you’ll find include:

• A non-destructive substitution with the /r flag: s///r
• New ways to specify binary, octal, and hexadecimal numbers.
• given returns its last evaluated expression (like if-elsif already does).
• srand returns its seed so you can reuse it.

You may have never heard of formats, but, believe it or not, they were an exciting feature 20 years ago. Learning Perl, First Edition had an entire chapter on them, but that chapter disappeared in the Learning Perl, Third Edition, cutting formats out of this millineum. Formats might not be the new black, but they do have some class in an old-school sorta way.

Formats provide some attractive features:

• Automatic pagination and page numbering
• Nice columnar output formatting
• Easily lining up decimal points in numbers

You could handle all of this yourself, but why would you want to if formats can already do it for you? You can get close with pack or printf, but you have to do a lot of extra work that formats already do.

There is a modular version of formats in Perl6::Form. Indeed, one of the first reactions to Perl 6 was “You better not take away my formats!” to which Damian replied in Exegesis 7 “We’re not taking them away, just moving them to a module. Oh, and I’m making them even cooler!”. Or something like that. It was several years ago, you have to realize.

That doesn’t mean that Perl 5 formats are useless today. If you want to output palintext lists, as in actually put ink on paper, perhaps so you can take an inventory all of the cats in your house, then formats are quite useful. In this Item, you’ll create output that looks like:

Household Pet Inventory, Page  1

 ID   NAME          DIET            OUNCES
--------------------------------------------
 12   Buster        Tuna            1.00
  1   Mimi          Pounces         0.30
 37   Ginger        Fancy Feast     0.75
 19   Ellie         White Castle    9.99

First, you have to define the formats themselves. These are somewhat like named subroutine definitions in that they can appear anywhere in the file and are defined at compile time. Every format definition is at least three lines. In the first line, you use the format keyword, an identifier (which is conventionally all uppercase since formats have no sigil of their own), and an =. The middle lines, which you’ll see in a moment, are the form lines. Finally, you end the definition with a literal full stop, ., that has to be on the line by itself and at the beginning of the line:

format STDOUT =
... form lines goes here ...
.

The form lines have two parts, the picture lines, and the variables holding the values for the pictures. The pictures are quite sophisticated, like printf, which knows what sort of value it expects, but with the extra formatting. You’ll only see some of the simple pictures in this Item. Most picture fields will start with a @ to denote the start of the picture then have other characters to denote what sort of picture it is:

After each picture line, you specify variables whose values will fill in the pictures in the previous form line. You specify the variables in the same order as the picture fields, and you separate the variables in commas. You can put the variable anywhere you like in the line (as long as its in the right order), so you can line them up with their pictures. A simple, format, then looks like this:

format STDOUT =
@##   @<<<<<<<<<    @<<<<<<<<<<<    @#.##
$id,  $name,        $food,          $amount
.

As designed, the format name matches the bareword filehandle you'll use it with (but more on that later). You name the format STDOUT because you want to use it with the standard output file handle.

When you are ready to output some data, you use write. This design shows the age of formats since write doesn't take arguments to fill in the pictures. It uses the variables that are in scope. The argument it does take, however, is the filehandle you want to write to:

our( $id, $name, $food, $amount ) = qw( 12 Buster Tuna 1.0 );
write();

If you don't specify a filehandle, write uses the current default filehandle. Putting that all together, you have:

use strict;
use warnings;

our( $id, $name, $food, $amount ) = qw( 12 Buster Tuna 1.0 );
write();

format STDOUT =
@##   @<<<<<<<<<    @<<<<<<<<<<<    @#.##
$id,  $name,        $food,          $amount
.

When you run this starter program, you get a single line of output:

 12   Buster        Tuna             1.00

That's fine, but you probably want to know what those columns are. There's a special format for that, too. By appending _TOP to the end of the format name, Perl knows to add a header when it starts a new page. This top-of-page format is like the previous format:

#!perl
use strict;
use warnings;

our( $id, $name, $food, $amount ) = qw( 12 Buster Tuna 1.0 );
write();

format STDOUT =
@##   @<<<<<<<<<    @<<<<<<<<<<<    @#.##
$id,  $name,        $food,          $amount
.

format STDOUT_TOP =
 ID   NAME          DIET            OUNCES
--------------------------------------------
.

Now your report comes out with column headers:

 ID   NAME          DIET            OUNCES
--------------------------------------------
 12   Buster        Tuna             1.00

Perl's formats are smart enough to know which page of output they are on, and they store that in the $% variable. You can use that to fill in a picture in the top-of-page format:

format STDOUT_TOP =
Household Pet Inventory, Page @#
                              $%

 ID   NAME          DIET            OUNCES
--------------------------------------------
.

Now your report has more information at the top, which will appear every time the format starts a new page:

Household Pet Inventory, Page  1

 ID   NAME          DIET            OUNCES
--------------------------------------------
 12   Buster        Tuna             1.00

When does a format start a new page, though? The formats know how many lines are in a page. That's in the $= variable, which you can set yourself if you don't want the default 60 lines. The formats are also keeping track of the the number of lines it has output so far. When it reaches the number of lines per page, it outputs a page break to end the page. This is a form feed, so no matter how much physical space you have left on the sheet of paper, your printer should spit it out and move on to the next sheet of paper. The formats then output the top-of-page information and continue where they left off. The \f in this output represents the page break:

Household Pet Inventory, Page  1

 ID   NAME          DIET            OUNCES
--------------------------------------------
 12   Buster        Tuna            1.00
  1   Mimi          Pounces         0.30
....many other lines....

\fHousehold Pet Inventory, Page  2

 ID   NAME          DIET            OUNCES
--------------------------------------------
 78   Roscoe        Turkey babyfood 0.15

Using formats with modern Perl

Formats are a bit antiquated. They've been a feature since Perl only had bareword filehandles so they look a bit clunky in the world of filehandles stored in variables. By default, formats look for a format name that matches the filehandle you want to write to. That is, if you want to send yout output to STDOUT, you name your formats STDOUT and STDOUT_TOP. However, plenty of experienced Perlers will complain when they see you using bareword filehandles.

It's easy to use formats with filehandles you store in scalar variables, though. You just have to tell Perl which format names it should use. As with many things in Perl, you can change special variables to do this. The per-filehandle variables $~ and $^ hold the names of the format and top-of-page format respectively. As with any of the per-filehandle special variables, each filehandle has their own versions of these and you can only set them on the default filehandle. Thus, you use select to change the default filehandle:

open my $fh, '>', $filename or die ...;
{
my $old_default = select( $fh );
$^ = 'CAT_INVENTORY_TOP';
$~ = 'CAT_INVENTORY';
select( $old_default );
}

You write to a filehandle by specifying it as an argument:

write( $fh );

Formats are also a bit crufty because you don't pass arguments to write to fill in the pictures. Perl relies on variables with the specified names being in scope. You can use lexical variables, but they have to be in the same scope as the format definition, and they have to be in scope when you call write. It's impractical to do that with lexicals, so the most agile way involves localized package variables:

foreach my $record ( @cats ) {
	local( $id, $name, $food ) = @$record;
	write( $fh );
	}

That somewhat mitigates the cruftiness of the format design, and that's about the best that you can do. If formats provide the features you need, however, then its not that annoying to deal with their eccentricities.

Things to remember

• Use formats to create paginated text reports
• Set the format names yourself when you use a filehandle in a variable
• Use localized package variables to set data for the format

delete local $hash{$key};
delete local $array[$index];

This syntax has actually been valid since at least Perl 5.6, although until Perl 5.12 it didn’t do anything different than a normal delete. Using it doesn’t even issue a warning:

$ perl5.6.2 -we 'delete local $ENV{PATH}'

This is documented in both in perlfunc and, curiously, perlsub

Temporarily delete hash keys

Setting up an inherited environment is one common reason that you would want to temporarily delete hash keys. You don’t want some values set when you run an external program:

{
delete local $ENV{DISPLAY};
system( 'some_program', @args );
}

Before Perl 5.12, you could temporarily delete hash keys in two steps. The first step requires you to assign the current hash to a new local version so you start off with all the current values. In the second step, you can delete the keys that you don’t want:

use Data::Dumper;

%ENV = qw(
	PATH     /usr/bin:/usr/local/bin
	PERL5LIB /Users/buster/lib/perl5
	DISPLAY  localhost:0
	);

print_env( 'Top level = ' );

{
local %ENV = %ENV;      # Step 1
delete $ENV{PATH};      # Step 2

print_env( 'Inner level = ' );
}

print_env( 'Back at top level = ' );

sub print_env {
	print @_, Dumper( \%ENV ), "\n";
	}

The output shows you that the PATH key temporarily disappears:

Top level = $VAR1 = {
          'DISPLAY' => 'localhost:0',
          'PERL5LIB' => '/Users/buster/lib/perl5',
          'PATH' => '/usr/bin:/usr/local/bin'
        };

Inner level = $VAR1 = {
          'DISPLAY' => 'localhost:0',
          'PERL5LIB' => '/Users/buster/lib/perl5'
        };

Back at top level = $VAR1 = {
          'DISPLAY' => 'localhost:0',
          'PERL5LIB' => '/Users/buster/lib/perl5',
          'PATH' => '/usr/bin:/usr/local/bin'
        };

Deleting a hash key is different from localizing the key and setting an undef value (which is the same as not giving it a new value):

{
local $ENV{PATH};

print_env( 'Inner level = ' );
}

This doesn’t remove the hash key, which might be important:

Inner level = $VAR1 = {
          'DISPLAY' => 'localhost:0',
          'PERL5LIB' => '/Users/buster/lib/perl5',
          'PATH' => undef
        };

The presence of a key, even with an undef value, can mean something much different than the absence of a key. For instance, you might not get the default value your application might set when the hash key is missing.

Do it in one step with Perl 5.12

You can get the same thing with one step with Perl 5.12, and you get the same output as the first program:

use 5.012;

use Data::Dumper;

%ENV = qw(
	PATH     /usr/bin:/usr/local/bin
	PERL5LIB /Users/buster/lib/perl5
	DISPLAY  localhost:0
	);

print_env( 'Top level = ' );

{
delete local $ENV{PATH};       # All together now

print_env( 'Inner level = ' );
}

print_env( 'Back at top level = ' );

sub print_env {
	say @_, Dumper( \%ENV );
	}

This even works for a hash slice so you can temporarily remove several keys. The syntax works out nicely because there’s nothing else to set:

use 5.012;
delete local @ENV{qw( PATH DISPLAY )};

Curiously, this also works with lexical hashes, which you might not expect since the syntax uses local. Even though you use a lexical hash, it’s the change to the hash that’s local. That’s a bit weird. You can rearrange the print_env subroutine to be an anonymous subroutine defined at runtime so it can use the lexical variable:

use 5.012;

use Data::Dumper;

my %env = qw(
	PATH     /usr/bin:/usr/local/bin
	PERL5LIB /Users/buster/lib/perl5
	DISPLAY  localhost:0
	);
my $print_env = sub { say @_, Dumper( \%env ); };

$print_env->( 'Top level = ' );

{
delete local @env{qw( PATH DISPLAY )};       # All together now

$print_env->( 'Inner level = ' );
}

$print_env->( 'Back in top level = ' );

Temporarily undefined array values

The delete local syntax also works with arrays, although it’s a bit different from the hash effect. When you delete an array element, you just set the value at that index to undef. That means that the array index is still there and the array does not change length (unless you’re deleting from the end):

use 5.012;
use Data::Dumper;

my @array = qw(buster mimi roscoe ginger ellie);

my $print_array = sub { say @_, Dumper( \@array ); };

$print_array->( 'Top level = ' );

{
delete local $array[2];

$print_array->( 'Inner level = ' );
}

$print_array->( 'Back at top level = ' );

The output shows a hole in the array:

Top level = $VAR1 = [
          'buster',
          'mimi',
          'roscoe',
          'ginger',
          'ellie'
        ];

Inner level = $VAR1 = [
          'buster',
          'mimi',
          undef,
          'ginger',
          'ellie'
        ];

Back at top level = $VAR1 = [
          'buster',
          'mimi',
          'roscoe',
          'ginger',
          'ellie'
        ];

If you temporarily want the array to not have an element, you’re in a bit of a pickle because you have to deal with package and lexical variables differently, although each requires you to make a copy.

Things to remember

If you have Perl 5.12 or later, you can:

• temporarily removes a hash key with delete local $hash{$key}.
• temporarily undefined an array element with delete local $array[$index].
• apply delete local to lexical variables.
• use delete local with slices.

In addition to adding the CAPTCHA, we deleted some of the user names that looked like fake users. If we accidentally deleted your real user account, we apologize. We made sure not to delete any accounts that had made legitimate comments.

I wrote some code to loop over lines in a file and modify a couple of elements in each line. My code seems very innocent, but the actual field modifications were a little more complex; I replaced them with lc and uc to make things simple for this example:

while (<>) {
  chomp;
  my @x = split "\t";
  $x[3] = lc $x[3];
  $x[5] = uc $x[5];
  print join("\t", @x), "\n";
}

I have a loop that splits each line of a file on the tab character then modifies the fourth and sixth field.
Look closely at the loop: I’m making Perl do a lot more work than it needs to.

First, I cal chomp on each line, but I’m adding the newline right back. There is no reason to do that. If I leave it there I get the same result:

while (<>) {
  my @x = split "\t";
  $x[3] = lc $x[3];
  $x[5] = uc $x[5];
  print join("\t", @x);
}

chomping when I don’t need to is a minor issue, but it is not likely going to destroy the performance of any program.

Looking a little closer, I see a much bigger inefficiency if I know the format of the data. Assume each line of data contains many fields; many being some number greater than six in this specific example. Since I’m are only acting on fields four and six, why do I split the entire line just to put it back together?

With a couple of more arguments, I can tell split to limit the number of fields it creates. I can limit my results to seven items since I don’t care to modify any beyond that:

while (<>) {
  my @x = split "\t", $_, 7;
  $x[3] = lc $x[3];
  $x[5] = uc $x[5];
  print join("\t", @x);
}

If each line only contains seven, or even ten, elements, I won’t see much if any improvement. However, if each line contains dozens or hundreds of fields, my potential speed-up is huge.

There is even more I can do to milk performance out of my loop if I control the data format. If I move the columns that I need to modify to the front of each row, I don’t need to split into so many fields:

while (<>) {
  my @x = split "\t", $_, 3;
  $x[0] = lc $x[0];
  $x[1] = uc $x[1];
  print join("\t", @x);
}

Measure the improvement

Just to be sure that these changes are really making my code faster, I do a little benchmarking to get a feel for the relative performance differences:

use warnings;
use strict;
use Benchmark qw(timethese);

my @data;

for (0..10_000) {
  $data[$_] = join "\t", map { chr(65 + (int rand(52))) } (0..100);
}

timethese(500, {
  'standard' => sub {
    for (@data) {
      chomp;
      my @x = split "\t";
      $x[3] = lc $x[3];
      $x[5] = uc $x[5];
      $_ = join("\t", @x) . "\n";
    }
  },
  'no_chomp' => sub {
    for (@data) {
      my @x = split "\t";
      $x[3] = lc $x[3];
      $x[5] = uc $x[5];
      $_ = join("\t", @x);
    }
  },
  'smaller' => sub {
    for (@data) {
      my @x = split "\t", $_, 7;
      $x[3] = lc $x[3];
      $x[5] = uc $x[5];
      $_ = join("\t", @x);
    }
  },
  'smallest' => sub {
    for (@data) {
      my @x = split "\t", $_, 3;
      $x[0] = lc $x[0];
      $x[1] = uc $x[1];
      $_ = join("\t", @x);
    }
  },
});

In this benchmark I experimented on ten thousand records, each with a hundred fields. The benchmarks measure:

• the initial, or “standard” case.
• the case where I just removed a chomp, “no_chomp”.
• the case where I limit split, “smaller”.
• the case where I reorder the inbound data, “smallest”.

The [reordered] results tell me quite a bit:

Benchmark: timing 500 iterations of no_chomp, smaller, smallest, standard…
standard: 451 wallclock secs (449.66 usr + 0.34 sys = 450.00 CPU) @ 1.11/s (n=500)
no_chomp: 451 wallclock secs (446.18 usr + 0.41 sys = 446.59 CPU) @ 1.12/s (n=500)
smaller: 39 wallclock secs (39.15 usr + 0.03 sys = 39.18 CPU) @ 12.76/s (n=500)
smallest: 19 wallclock secs (18.98 usr + 0.01 sys = 18.99 CPU) @ 26.33/s (n=500)

Removing chomp had an almost unnoticeable effect. However, I recuded my processing tenfold by limiting split. I made my code even faster by reordering the inbound data.

Just to see what effect number of fields really has, I reduced the size of the data so that each record had ten fields. The results were obviously less impressive, though still visible:

Benchmark: timing 500 iterations of no_chomp, smaller, smallest, standard…
standard: 58 wallclock secs (57.50 usr + 0.05 sys = 57.55 CPU) @ 8.69/s (n=500)
no_chomp: 55 wallclock secs (55.13 usr + 0.04 sys = 55.17 CPU) @ 9.06/s (n=500)
smaller: 38 wallclock secs (37.67 usr + 0.03 sys = 37.70 CPU) @ 13.26/s (n=500)
smallest: 18 wallclock secs (18.46 usr + 0.01 sys = 18.47 CPU) @ 27.07/s (n=500)

So what does this tell me? Well, as far as a specific optimization goes, limiting split is probably a good idea if I’m trying to optimize my processing and really don’t need every field.

However, there is a larger moral to this story and that is: When performance is a concern, don’t make your code do work that it doesn’t have too. The most important is my choice of algorithms and related data structures for solving my problem. This can make or break my performance. After that, knowing specific optimizations such as limiting split fields, help me get just a little more performance out of my code.

We’re thinking about writing an extra, bonus chapter of Effective Perl Programming for Safari Books Online. We’re having fun providing lots of free, extra content on this website, but we thought we might do something nice for those you also paid to get online access to our book.

Before we commit to too much, we’d like to find out a little bit about our readers to make sure it’s worth it:

• How many of you are reading Effective Perl Programming through Safari?
• Does your company provide you with an unlimited Safari account?
• If we added bonus material, would you be more likely to buy our book in Safari?
• If you don’t want to use Safari, would you be more likely to buy another e-book format with extra content?
• If you aren’t reading our book in a digital form, why not? Is there anything that would change your mind?

We’re still going to pump out more Effective Perler tips and techniques for free (It’s already August and we’ve done at least one significant post per week this year!).

use 5.012;

This is really just the same thing as explicitly turning on strict and importing the 5.12 feature bundle:

use strict;
use feature ':5.12';

Note that this means merely importing the feature bundle does not include this implicit strictures benefit. Don’t think you’re safe merely because you are using a perl5.12 interpreter.

Similarly, using the -E switch, which imports the feature bundle for that version of Perl, does not turn on strictures. You can import strict explicitly (although you are probably not interested in strictures on the command line):

% perl5.12.1 -E '$sum = 0;'
% perl5.12.1 -Mstrict -E '$sum = 0;'
Global symbol "$sum" requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.

Remember, however, that strict is lexically scoped, and that a file is a scope (Know what creates a scope). That is, the use 5.012 only affects the file that it is in, but any files it loads do not have to be strict-clean.

Consider this strict-dirty module:

# NoStrict.pm
package NoStrict;

$sum = 0;

1;

When you load it in a program, any strict settings do not descend into NoStrict.pm:

use 5.012;

use lib qw(.);
use NoStrict; # strict dirty module

my $sum = 0;

When you run this program, it compiles just fine:

perl5.12.1 strict.pl

To get around this, you have to set strict in every file you want to apply it to.

Things to remember

• use 5.012 turns on strictures in it’s file
• The implicit strictures feature is not part of the 5.12 feature bundle
• The -E command-line switch does not turn on strictures.

use 5.012;

use Switch;             # use given-when
use UNIVERSAL qw(can);  # no more UNIVERSAL->import

$[ = 1;       # I like FORTRAN.
my $pi := 4;  # empty attribute, not a special assignment

OUTER: {
	goto INNER;  # can't jump into inner scope
	...;
	MIDDLE: {
		...;
		INNER: {
			hello();
			}
		}
	}

sub hello :locked { # no more locked attribute
	say 'Here I am!';
	}

When you run this program, you get some warnings:

% perl5.12.1 old_stuff.pl
Use of assignment to $[ is deprecated at old_stuff.pl line 6.
Use of := for an empty attribute list is deprecated at old_stuff.pl line 7.
Use of :locked is deprecated at old_stuff.pl line 20.
Use of "goto" to jump into a construct is deprecated at old_stuff.pl line 9.
Here I am!

If you enable warnings, you get even more deprecation warnings:

% perl5.12.1 -w old_stuff.pl
Switch will be removed from the Perl core distribution in the next major release. Please install it from CPAN. It is being used at old_stuff.pl, line 3.
UNIVERSAL->import is deprecated and will be removed in a future perl at old_stuff.pl line 4
Use of assignment to $[ is deprecated at old_stuff.pl line 6.
Use of := for an empty attribute list is deprecated at old_stuff.pl line 7.
Use of :locked is deprecated at old_stuff.pl line 20.
Use of "goto" to jump into a construct is deprecated at old_stuff.pl line 9.
Here I am!

If you still want to use these features, despite Perl doing everything it can to warn you not to, you can explicitly turn off the deprecation warning class:

use 5.012;
no warnings 'deprecated';

# same as before...

Now you just get the output that you wanted:

$ perl5.12.1 -w old_stuff.pl
Here I am!

You shouldn’t turn off these warnings as a long term strategy. If you’re migrating your ancient Perl to the latest version and want these warnings to temporarily disappear while you focus on some other things, we can let that pass. You might want to give yourself a reminder that you’ve turned off all of these important warnings by checking for warnings as we showed in Item 100: Use lexical warnings to selectively turn on or turn off complaints

use 5.012;
no warnings ‘deprecated’;
temp_warning();

sub temp_warning {
	# needs to be one level lower than the warnings setting
	warn “Hey Evel Knievel! Deprecation warnings are disabled!” unless
		warnings::enabled( ‘deprecated’ );
	}

…;

It's important that you put your check inside a subroutine because warnings::enabled is specifically designed to look on level above where you call it since it's expecting you to use it in a module to respect the state of the calling script.

Since the warnings pragma is lexically scoped, you might have to do this in several places (unless the modules respect the warnings settings of the caller!). Don't expect anyone to rush to make it any easier for you to disengage the safety devices, though!

Somewhere along the process, you might discover that something is not working correctly. You think that it used to work but you’re not sure where things went pear-shaped, perhaps because the bug seemingly deals with something that you weren’t working on.

You might think that your test suite should catch those, but a test suite doesn’t protect you from bugs. Your tests might not have checked for the problem, or your tests might have been wrong, or all sorts of other things that you don’t expect. Your tests are only as good as you make them, and often the programmer creates his own tests and acts as his own quality control (which isn’t the best of arrangements).

Since you’re keeping your work in source control (we’ll give you the benefit of the doubt), you can easily, at least in process, figure out where the problem appears by bisecting your source tree until you find the revision that introduces the problem:

1. check out a revision where things don’t work
2. verify broken behavior with a test script
3. check out a revision where you think things work
4. verify working behavior with a test script
5. check out a revision halfway between the working and broken versions
6. run the test script to check if that revision works or breaks
7. repeat this bisection until you find revision that breaks

With each iteration, you narrow the window of revisions where you might have introduced the problem.

This is simple in process, but it’s tedious in practice. With any source control system, you can manually checkout a revision, run your check script, and see what happens. You can keep doing that until you find the problem. You can even automate it.

Some modern source control systems, however, provide a bisection feature for you so you don’t have to automate it yourself. For this Item, consider git, which is popular in the Perl community (and the perl source is in a git repository). Read perl5-porters for a couple of days and you’re likely to read about some of the developers using git bisect to find a bug in perl.

As a demonstration, you can use the Buster::Bean git repository. In that module which simulates my cat, there’s a complaino subroutine that should return a string that has “meow” in it, but somewhere along the line it broke. The t/export.t test checks for this, and you notice in the latest revision that the t/export.t test doesn’t pass.

# t/export.t
like( complaino(), qr/meow/i, 'complaino returns something like a meow' );

The current version of complaino is broken, but you don’t remember when it broke:

# lib/Bean.pm
sub complaino {
	return 'MEOOOOOW!' # this versions is broken
	}

Once you unpack the distribution, change into the Buster-Bean directory if you want to follow along.

To start your hunt, you tell git that you are starting a bisection:

% git bisect start

Next you have to set the initial window. As with many things in git, you can specify the revision in various way. In this case, you can use the start of the SHA-1 digest for each commit. You set the good and bad bounds of the window:

% git bisect good 4be027af
% git bisect bad 14883968

Once you’ve set the window for your bisection, you run the bisection by specifying a test script to run for each commit that git will check:

% git bisect run ./test-script.sh

The trick is to write a test script that tells git if the revision works or not. If your test script exits with 0, you’re telling git that the revision works. If your test script exits with 1-127, that commit fails (although exiting with 125 tells git to skip that revision).

How you write your test script depends on what you want to check. In the case of complaino, you want to find where the t/export.t test starts to fail. You might think that you can just run the your test script:

% git bisect run perl -Iblib/lib t/export.t

However, that might not put the right versions of the modules in blib. In this case, you need to run Makefile.PL each time then make the source (or ./Build it to put everything in the righ place. With the right files, you run the program that provides the final exit code to tell git what happened:

#!/bin/sh

perl Makefile.PL
make
perl -Iblib/lib t/export.t

Now you’re to run the bisection:

% git bisect run ./meow_test.sh

The output shows git‘s progress through the revision history. The first revision it tests is in the middle of the the window you specified. In this case, that one passes, so it’s now the good bound of the window. The next revision is 93d1747, where t/export.t fails. That narrows the window on the bad side. The rest of the bisection tries revisions that all pass, so 93d1747 must be the revision that introduces that brokenness. git reports 93d1747... is first bad commit:

running ./meow_test.sh
Writing Makefile for Buster::Bean
Skip blib/lib/Buster/Bean.pm (unchanged)
Manifying blib/man3/Buster::Bean.3
1..4
ok 1 - use Buster::Bean;
ok 2 - Buster::Bean->can('complaino')
ok 3 - complaino subroutine is defined
ok 4 - complaino returns something like a meow

Bisecting: 3 revisions left to test after this
[93d1747e4681ea21536a66aba25bb21e1cddda05] Make uppercase
running ./meow_test.sh
Writing Makefile for Buster::Bean
cp lib/Bean.pm blib/lib/Buster/Bean.pm
Manifying blib/man3/Buster::Bean.3
1..4
ok 1 - use Buster::Bean;
ok 2 - Buster::Bean->can('complaino')
ok 3 - complaino subroutine is defined
not ok 4 - complaino returns something like a meow
#   Failed test 'complaino returns something like a meow'
#   at t/export.t line 10.
#                   'MEOOOOOW!'
#     doesn't match '(?i-xsm:meow)'
# Looks like you failed 1 test of 4.

Bisecting: 1 revisions left to test after this
[980be46fa2ea3ee32372aedd62949a663c729058] * Use fewer exclamation points
running ./meow_test.sh
Writing Makefile for Buster::Bean
cp lib/Bean.pm blib/lib/Buster/Bean.pm
Manifying blib/man3/Buster::Bean.3
1..4
ok 1 - use Buster::Bean;
ok 2 - Buster::Bean->can('complaino')
ok 3 - complaino subroutine is defined
ok 4 - complaino returns something like a meow

Bisecting: 0 revisions left to test after this
[b5ab15611ca25c6925998463c9cb7b079fe87c8b] * Make it lowercase
running ./meow_test.sh
Writing Makefile for Buster::Bean
cp lib/Bean.pm blib/lib/Buster/Bean.pm
Manifying blib/man3/Buster::Bean.3
1..4
ok 1 - use Buster::Bean;
ok 2 - Buster::Bean->can('complaino')
ok 3 - complaino subroutine is defined
ok 4 - complaino returns something like a meow

93d1747e4681ea21536a66aba25bb21e1cddda05 is first bad commit
commit 93d1747e4681ea21536a66aba25bb21e1cddda05
Author: brian d foy 
Date:   Mon Jul 19 20:43:07 2010 -0500

    Make uppercase

:040000 040000 8360932159317f0685b98f2b2dba4753c53e6240 0e7a2e5d54de7db9f1b790ed4da0a704612ba130 M  lib
bisect run success

Graphically, that bisection looks like this, starting at the top and going toward the bottom for ① then on its way back toward the top for ②, alternating directions as it closes in on the bad revision:

When you are done with the your bisection, you need to tell git to return to the head of the source tree:

% git bisect reset

Other source control systems have a bisection feature which do basically the same thing although their details might be different. If your source control system doesn’t have this feature, you can automate it (or switch to a system that does have it). Once set-up, you should be be able to locate bugs much quicker.

Other authors confirmed so far include:

• chromatic (Modern Perl, Perl Testing: A Developer’s Notebook, Perl Hacks, Extreme Programming Pocket Guide)

• brian d foy (Effective Perl Programming, Learning Perl, Intermediate Perl, Mastering Perl)

• Joshua McAdams (Effective Perl Programming)

• Curtis “Ovid” Poe (Perl Hacks)

• Randal Schwartz (Programming perl (1st edition), Learning Perl, Intermediate Perl, Perls of Wisdom)

• Peter Scott (Perl Medic, Perl Debugged, Perl Fundamentals (DVD))

Make sure that you’re going to Powell’s Technical Books is at 33 Northwest Park Avenue in Portland, and not one of their other Portland stores. You can take the MAX Green line (for free) from the Convention Center to NW 5th St and NW Couch St, then walk 4 blocks west to the store.

For many programmers, this practice begins to break down when “configuration” code is involved. When I talk about configuration code here, I’m not talking about the XML, YAML, INI, and other non-moving bits of your project. I’m talking about the Perl code in your program that simply serves as data to feed some active portion of your code. For example:

my @anchors = (
  {
    text => 'Effective Perl',
    href => 'http://www.effectiveperlprogramming.com'
  },
  {
    text => 'Perl',
    href => 'http://www.perl.org'
  },
);

for my $anchor (@anchors) {
  create_anchor_tag($anchor);
}

Here I have avoided repeating myself by consolidating all of the common logic for anchor processing into create_anchor_tag. My code loops the configuration data structure and simply feeds a little bit of configuration at a time into that subroutine.

This type of configuration works most of the time, especially when code is first written. Unfortunately, it breaks down quickly as the configuration becomes more complex over time. Say for instance that we now have more anchors and need to be more specific about the details of each anchor.

my @anchors = (
  {
    text  => 'Effective Perl',
    href  => 'http://www.effectiveperlprogramming.com',
    class => 'standard',
    style => '',
    lang  => 'en',
    dir   => 'ltr'
  },
  {
    text  => 'Perl',
    href  => 'http://www.perl.org',
    class => 'standard',
    style => '',
    lang  => 'en',
    dir   => 'ltr'
  },
  {
    text  => 'Perl Foundation',
    href  => 'http://www.perlfoundation.org',
    class => 'standard',
    style => '',
    lang  => 'en',
    dir   => 'ltr'
  },
  {
    text  => 'Perl6 России',
    href  => 'http://www.perl6.ru',
    class => 'standard',
    style => '',
    lang  => 'ru',
    dir   => 'ltr'
  },
  # ... and so on
);

You can see, that beyond simply repeating the hash keys over and over, I am also repeating quite a few of the hash values. For instance, the values for class, lang, and dir are fairly consistant. When you see this pattern occurring in your code, it is time to do a little refactoring. Luckily, refactoring repetitiveness out of code is often very easy.

A common strategy for refactoring is to simply inline a map statement into the configuration setup. In the example below, I have inserted a map that handes the portions of the configuration that change the least. It provides default values that represent the most commonly used configuration values and also allows for overrides by overlaying the anchor-specific hash at the end of the map.

my @anchors = map { {
    class => 'standard',
    style => '',
    lang  => 'en',
    dir   => 'ltr',
    %{$_}
  } } (
  {
    text => 'Effective Perl',
    href => 'http://www.effectiveperlprogramming.com'
  },
  {
    text => 'Perl',
    href => 'http://www.perl.org'
  },
  {
    text => 'Perl Foundation',
    href => 'http://www.perlfoundation.org'
  },
  {
    text => 'Perl6 России',
    href => 'http://www.perl6.ru',
    lang => 'ru'
  },
  # ... and so on
);

This simple tweak to the configuration setup significantly reduces the amount of redundancy in the code. Programmers who maintain this code can quickly see what the default values are for all of our anchor tags and can also more easily see the tags with customizations. When all of the options were specified for every anchor, it was easy to miss the meaningful configuration that made the anchors unique. There was way too much noise with the repeated code.

We can take our DRY’ness a step further now by removing the repeated hash keys in the configuration. Every anchor will have a different bit of text and a different link, so those keys will be present for every single configuration. Why declare them every time? Well, one reason is that it serves as good documentation. However, when you only have a couple of required options, positional notation is fine.

In this example, I’m storing each anchor’s configuration in an anonymous array. I’m assuming that the first two elements of the array are always the text and link for the anchor. Everything else is a customization.

my @anchors = map { {
    text  => shift @{$_},
    href  => shift @{$_},
    class => 'standard',
    style => '',
    lang  => 'en',
    dir  => 'ltr',
    @{$_}
  } } (
    [ 'Effective Perl' => 'http://www.effectiveperlprogramming.com' ],
    [ 'Perl' => 'http://www.perl.org' ],
    [ 'Perl Foundation' => 'http://www.perlfoundation.org' ],
    [ 'Perl6 России' => 'http://www.perl6.ru', lang => 'ru' ],
    # ... and so on
);

Now the configuration is very succinct and easy to read compared to its wordy successor. There is very little noise and no repeated code. Each configured anchor is as customizable as when we started. The common elements are only mentioned once and the differences are all that we see.

my $dbh = DBI->connect( ..., ..., \%attr );

my $sth = $dbh->prepare( ..., \%attr );

There are several attributes that affect error handling, each of which you can use with either a connection or a statement handle:

These attributes are inherited by anything derived from the handle where you set them.

The PrintWarn and PrintError attributes do just what they say. They are on by default, and they don’t stop your program. In this example, you prepare a statement that expects one bind parameter, but when you execute it, you give two parameters instead:

use DBI;

my $dbh = DBI->connect( 'dbi:SQLite:dbname=test.db', '', '', {} );

my $sth = $dbh->prepare( 'SELECT * FROM Cats WHERE id = ?' );
$sth->execute( 1, 2 );

while( my @row = $sth->fetchrow_array ) {
	print "row: @row\n";
	}

print "Got to the end\n";

Since PrintError is true by default, DBI prints the error, but it allows the program to continue even though there was an error:

DBD::SQLite::st execute failed: called with 2 bind variables when 1 are needed at dbi-test.pl line 12.
Got to the end

If you set the ShowErrorStatement attribute, you get a better error message because DBI appends the SQL statement that you tried to execute. You can set this either database handle or the statement handle, but if you don’t know which statement is causing the problem, it’s easier to set it as part of the database handle:

# The rest of the program is the same
my $dbh = DBI->connect( 'dbi:SQLite:dbname=test.db', '', '', {
	ShowErrorStatement => 1,
	} );

The error message shows the SQL statement, but the program still continues:

DBD::SQLite::st execute failed: called with 2 bind variables when 1 are needed [for Statement "SELECT * FROM Cats WHERE id = ?"] at dbi-test.pl line 12.
Got to the end

The RaiseError attribute turns errors into fatal errors that you can trap with eval { ... } or Try::Tiny (Item 103: Handle Exceptions Properly) (or not trap if you want your program to die):

# The rest of the program is the same
my $dbh = DBI->connect( 'dbi:SQLite:dbname=test.db', '', '', {
	RaiseError         => 1,
	ShowErrorStatement => 1,
	} );

use Try::Tiny;

try {
	$sth->prepare( ... );
	$sth->execute( ... );
	}
catch {
	...
	};

The output shows that the program stops (there’s no “Got to the end”), but you see duplicated error messages; the one from PrintError that is just a warning, and the one from RaiseError that kills the program:

DBD::SQLite::st execute failed: called with 2 bind variables when 1 are needed [for Statement "SELECT * FROM Cats WHERE id = ?"] at dbi-test.pl line 14.
DBD::SQLite::st execute failed: called with 2 bind variables when 1 are needed [for Statement "SELECT * FROM Cats WHERE id = ?"] at dbi-test.pl line 14.

Turning off PrintError can fix the duplication:

# The rest of the program is the same
my $dbh = DBI->connect( 'dbi:SQLite:dbname=test.db', '', '', {
	PrintError         => 0,
	RaiseError         => 1,
	ShowErrorStatement => 1,
	} );

Simply raising the exception might be good enough for some applications, but sometimes you want more control of the errors. In those cases, you can handle the errors yourself by providing a code reference to HandleError. In this case, you can just catch the error and print it:

my $dbh = DBI->connect( 'dbi:SQLite:dbname=test.db', '', '', {
	ShowErrorStatement => 1,
	HandleError        => \&dbi_error_handler,
	} );

sub dbi_error_handler {
	my( $message, $handle, $first_value ) = @_;

	print "Caught: $message\n";

	return 1;
	}

DBI passes your HandleError three arguments: the error string it would have used with PrintError, the handle that generated the error, and first return value from the failing method (which is typically nothing useful since there’s an error of some sort).

The error message shows the you caught the error:

Caught: DBD::SQLite::st execute failed: called with 2 bind variables when 1 are needed [for Statement "SELECT * FROM Cats WHERE id = ?"]
Got to the end

If you want a stack trace, you can use Carp (and curiously, the argument alignment works out!).

use Carp;

my $dbh = DBI->connect( 'dbi:SQLite:dbname=test.db', '', '', {
	ShowErrorStatement => 1,
	HandleError        => \&Carp::confess,
	} );

HandleError is how Exception::Class::DBI inserts its error handler:

my $dbh = DBI->connect( $dsn, $user, $pass, {
	PrintError  => 0,
	RaiseError  => 0,
	HandleError => Exception::Class::DBI->handler,
	});

The DBIx-Log4perl uses HandleError, although it hides the details from you:

my $dbh = DBIx::Log4perl->connect('dbi:Oracle:XE', 'user', 'password');

There are some things that you might want to do when handling the error yourself, depending on what you want to accomplish:

• rollback if you are in the middle of a transaction
• disconnect from the database if you are going to quit
• reconnect to the database if you lost the connection
• print a stack trace

No matter what you want to do, however, it’s HandleError that lets you do it.

Things to remember

• The RaiseError attribute turns DBI handle warning into fatal errors
• You can handle errors yourself by giving HandleError a code reference
• Setting the ShowErrorStatement attribute adds the offending SQL statement to the error message

• Continuous Integration: CruiseControl and Perl
• Dependency Injection: Who Cares?
• Effective Perl: Unicode

They specifically list that these formats target Adobe Digital Editions, so I don’t know if they’ve checked them on any other readers or have used special features.

InformIT also has an “eBook” version, which I think is just a PDF, for $US28.79, but also has a “Book + eBook Bundle” for $US47.19. They might offer ePub in the future.

If anyone buys either the PDF or ePub versions from eBooks or InformIT, let us know what you think of them, how they look, and which reader you use.

use VERSION;

We covered this in Item 83: Limit your distributions to the right platforms, and we mentioned that it might invoke side effects. We didn’t get into the details in that Item though. As of Perl 5.10, this introduces side effects that you might not want.

Merely specifying a Perl version prior to 5.10 (well, actually before 5.9.5, the development track that led to 5.10) does nothing other than check the version you specify against the interpreter version. If the version you specify is equal to or greater than the interpreter version, your program continues. If not, it dies:

use 5.008;  # needs perl5.008000 or later

This works with require too:

require 5.008;  # needs perl5.008000 or later

However, use is a compile-time function and require is a run-time function. By the time you hit that require, perl has already compiled your program up to that point or died trying as it ran into unknown features. Code may have already run, despite using an inappropriate version of perl. You want to impose your version restriction as soon as possible.

You might think that you can fix this with a BEGIN block which compiles and immediately runs the code so you get the ordering right:

BEGIN { require 5.010; }

However, this also pulls in the new features for that version, at least in Perls 5.10 and 5.12, although that might be a bug. Even if it is, it still is what it is and you need to watch out for it.

use 5.010

With Perl 5.10, you get three side effects with use 5.010. Starting with that version, use-ing the version also pulls in the new features for that version. Obstensibly, that keeps programs designed for earlier versions breaking as newer perls add keywords, but it also tries to enforce the current philosophy of good programming on you.

Perl 5.10 introduces say, state, and given-which, which you import implicitly when you say use 5.010:

use 5.010;
say 'I can use Switch!';  # imported say()

given ($ARGV[0]) {        # imported given()
	when( defined ) { some_sub() }
	};

sub some_sub {
	state $n = 0;         # imported state()
	say "$n: got a defined argument";
	}

If you want to insist on Perl 5.010 but not use its new features, perhaps because that’s the installation with the necessary modules, you can unimport the side effects immediately with the new feature pragma:

use 5.010;     # implicit imports
no feature;    # take it right back again

# you're own version of say()
sub say {
	# something that you want to do
	}

If you only want some of the new features, you can unimport the ones that you don’t want:

use 5.010;
no feature qw(say);   # leaves state() and given()

sub say {
	# something that you want to do
	}

use 5.012

Perl 5.12 includes two more side effects for use VERSION. The unicode_strings feature treats all strings outside of bytes and locale scopes as Unicode strings. Additionally, use 5.012 automatically turns on strict:

use 5.012;
# now strictures are on

$foo = 1;   # compile-time error!

Again, you can’t get around this by using require because it still turns on the new features and enables strict:

BEGIN { require 5.012 }

$foo = 1;  # still a compile-time error

If, for some odd and dangerous reason you don’t want strict on by default, you can turn it off yourself, even though unimporting it doesn’t give you the warning that you’ve left the paved roads, you’ve just violated your rental car contract, and there’s a chainsaw massacrer waiting for you:

use 5.012;
no feature;
no strict;

my $foo = 1;   

$fo0++;  # sure, go ahead and make that error

A workaround to restrict perl versions

There’s a way around all of this, and it’s to not restrict the version with use if that’s the only thing that you want to do. Instead, you can check the value of the $] variable, just like the various examples you saw in Item 83:

BEGIN {
	die "Unsupported version"
		unless $] >= 5.010 and $] < 5.011
	}

This has the added benefit of restricting the upper acceptable perl version.

Things to remember

• use VERSION imports new features since Perl 5.9.5.
• BEGIN { require VERSION } still imports new features
• Use no feature or no strict to unimport unwanted features.
• Restrict the perl version with $].

Most of the class goes back to the basics and re-learning the handful of underlying rules in Perl. These are the things that we don’t get bogged down with in Learning Perl, where we want to get as much Perl in front of people as soon as possible so they can start writing Perl programs (no matter how ugly they might look). Effective Perl Programming, however, takes that to another level as Perlers come back to think about the subtle things that they ignored while they were trying to get the big picture. Learning any language is a spiralling effort to big up the big concepts then coming back around to refine them, over and over.

I’ve started to make a list of the handful of things that Perlers need to understand, and none of it has to do with tricky syntax. Many people never pick up these concepts, so they come up with complicated models to explain why things happen. Instead, the Perler just needs to understand:

• Data and variables are different things (e.g. lists and arrays)
• Operators matter more than data for deciding what happens
• Context is important (strings and numbers; scalar, list, and void)
• Run-time versus compile time, and when things happen despite their location in the code

Start with a simple file that has START and END markers:

# input.txt
Ignore this
Ignore this too
START
Show this
And this
Also this
END
Don't show this
Or this

You need to extract the lines between those two markers:

# flip-flop
while( <> ) {
	say if /START/ .. /END/;
	}

The output shows the just the stuff between those markers:

% perl flip-flop input.txt
START
Show this
And this
Also this
END

What if you make the file a bit more complicated so there is an extra matching window? Once the flip-flop operator goes back to false, it can turn to true once its lefthand side matches again. Here’s a file with two windows:

# input2.txt
Ignore this
Ignore this too
START
Show this
And this
Also this
END
Don't show this
Or this
START
Show this again
And this again
Also this again
END
But ignore this

Now you get both windows of output:

% perl flip-flop input2.txt
START
Show this
And this
Also this
END
START
Show this again
And this again
Also this again
END

That’s fine, but it gets a bit more complicated when you try to use the same flip flop more than once when you don’t know its state. Modify the flip-flop program so it goes through each file separately instead of combining all the files into the ARGV filehandle:

foreach my $file ( @ARGV )
	{
	open my $fh, '<', $file or die "Could not find $file\n";
	while( <$fh> ) {
		say if /START/ .. /END/;
		}
	}

To watch it work (or not work, coming later), split the input2a.txt file into two separate files, each of which has its own window you want to extract:

# input2a.txt
Ignore this
Ignore this too
START
Show this
And this
Also this
END
Don't show this

# input2b.txt
Or this
START
Show this again
And this again
Also this again
END
But ignore this

The output isn’t surprising and it looks the same as it did with the previous program:

% perl flip-flop input2a.txt input2b.txt
START
Show this
And this
Also this
END
START
Show this again
And this again
Also this again
END

However, it’s at this point that some people get confused. The flip-flip operator doesn’t care about which file you are looking at, what happened in the last file, and so on. To see it “break”, change input2a.txt to it doesn’t have the END marker:

# input2a.txt
Ignore this
Ignore this too
START
Show this
And this
Also this
Don't show this

Since input2a.txt doesn’t complete the window as you intended, the flip-flop, maintaining its state, is still true when it starts the second file:

% perl flip-flop input2a.txt input2b.txt
START
Show this
And this
Also this
Don't show this
# inputb.txt
Or this
START
Show this again
And this again
Also this again
END

The flip-flop maintains its global state. It doesn’t care about starting new loops, new iterations, or anything else. You might think that you could find that in a subroutine, but it’s not even safe there. Every flip-flop operator that perl compiles has its own state, and perl compiles a subroutine only once:

foreach my $file ( @ARGV )
	{
	open my $fh, '<', $file or die "Could not find $file\n";
	extract( $fh );
	}

sub extract {
	my( $fh ) = shift;

	while( <$fh> ) {
		print if /START/ .. /END/; # this is the same .. on every call
		}
	}

The output doesn’t change! The flip-flop doesn’t really care that it’s in a subroutine. It’s really just the same flip-flop like it was before.

So, if every flip-flop operator that perl compiles has its own state, and you want a flip-flop operator with a new state, you just need to compile a new flip-flop for each iteration. That’s simple enough, kinda. This program won’t work because the subroutine reference is the same each time. When perl compiles it, it knows that the anonymous subroutine is going to be the same each time so perl reuses it:

foreach my $file ( @ARGV )
	{
	open my $fh, '<', $file or die "Could not find $file\n";
	make_extractor()->($fh);
	}

sub make_extractor {
	sub { # only compiled once
		my( $fh ) = shift;

		while( <$fh> ) {
			print if /START/ .. /END/;
			}
		};
	}

You can verify this by dumping the return value of make_extractor:

# dump-subs.pl
use Devel::Peek;

my @subs = map { make_extractor() } 1 .. 3;

print Dump( $_ ) foreach @subs;

sub make_extractor {
	sub { # only compiled once
		my( $fh ) = shift;

		while( <$fh> ) {
			print if /START/ .. /END/;
			}
		};
	}

You get the same subroutine each time, which means you get the same flip-flop each time:

% perl dump-subs.pl
SV = RV(0x80f66c) at 0x80f660
  REFCNT = 2
  FLAGS = (ROK)
  RV = 0x81a4f0
  SV = PVCV(0x80e4b8) at ...
SV = RV(0x80f6fc) at 0x80f6f0
  REFCNT = 2
  FLAGS = (ROK)
  RV = 0x81a4f0
  SV = PVCV(0x80e4b8) ...
SV = RV(0x8030bc) at 0x8030b0
  REFCNT = 2
  FLAGS = (ROK)
  RV = 0x81a4f0
  SV = PVCV(0x80e4b8) ...

You have to make each subroutine different somehow. The trick is to use a closure, which is a subroutine that references a lexical variable that has gone out of scope. In this case, you can enlist state to keep track of how many flip-flop operators you make, and since each new anonymous subroutine needs to capture the value of $count, perl can’t reuse previous definitions. You force it to make a new subroutine:

# flip-flop
use 5.010;

foreach my $file ( @ARGV )
	{
	open my $fh, '<', $file or die "Could not find $file\n";
	make_extractor()->($fh);
	}

sub make_extractor {
	state $count = 0;
	$count++;

	sub {
		my( $fh ) = shift;

		while( <$fh> ) {
			print "$count: $_" if /START/ .. /END/;
			}
		};
	}

Now each file gets its own flip-flop. You can see where the first file ends (and is missing its marker) and the second file begins. Every file gets its own flip-flop:

% perl flip-flop input2a.txt input2b.txt
1: START
1: Show this
1: And this
1: Also this
1: Don't show this
2: START
2: Show this again
2: And this again
2: Also this again
2: END

For more information about flip-flops, see perlop’s entry for Range Operators.

Things to remember

• Every flip-flop maintains a global state
• Flip-flops are not scoped
• Create a new flip-flop by wrapping it in a closure

There’s a module that can tell you if anything in your program used one of these nasty variables. The Devel::SawAmpersand module uses the B backend to look for any compiled Perl code that deals with the internal sawampersand variable that, when true, automatically slows down all of your matches and substitutions. By inserting a couple of lines in at the top of your code, you can tell if Perl ran into sawampersand:

use Devel::SawAmpersand qw(sawampersand);
END { print "saw ampersand => ", sawampersand(), "\n" }

my $string = 'cat bird dog';

$string =~ m/\s*bird\s*/;

print <<"HERE";
\$`  =>  $`
\$&  =>  $&
\$'  =>  $'
HERE

The output shows you that it did indeed see at least one of those variables:

$`  =>  cat
$&  =>   bird
$'  =>  dog
saw ampersand => 1

That’s not very useful because it doesn’t tell you where it found the variables, and you had to change the source to find out. You really want to do this without changing the source and also have it tell you in which files and on which line numbers those variables appear. That’s what Devel::FindAmpersand does:

my $string = 'cat bird dog';

$string =~ m/\s*bird\s*/;

print <<"HERE";
\$`  =>  $`
\$&  =>  $&
\$'  =>  $'
HERE

Now I run the program by loading the Devel::FindAmpersand module on the command line (in this case, reporting the line number where the string starts):

$ perl5.10.1 -MDevel::FindAmpersand amp.pl
$`  =>  cat
$&  =>   bird
$'  =>  dog
Found evil variable $` in file amp.pl, line 5
Found evil variable $& in file amp.pl, line 5
Found evil variable $' in file amp.pl, line 5

That’s fine for finding the variables in the same file, but what if they are in a different module? Devel::FindAmpersand only reports what it finds in the main script. Here’s a script that pulls in a library that uses one of the match variables:

require 'uses-amp.pl';

my $string = 'cat bird dog';

$string =~ m/\s*bird\s*/;

print "Pre-match is $PREMATCH\n";

Here’s the tiny culprit library:

# this is a naughty module

my $matched = $&;

1;

Devel::FindAmpersand doesn’t complain though, since the $& doesn’t appear in the main file:

$ perl -MDevel::FindAmpersand amp.pl
Pre-match is cat

Since you’re really only doing this during development and probably infrequently, you can rig a solution to search through any loaded files. Create a small module that uses an END block to go through all of the files listed in %INC and examine each individually:

# ScanAmpersand.pm
END {
	foreach my $file ( values %INC ) {
		system $^X, '-MDevel::FindAmpersand', $file;
		}
	}

1;

When you use your ScanAmpersand, you get warnings from any files that used one of the variables:

$ perl -MScanAmpersand amp.pl
Pre-match is cat
Found evil variable $& in file uses-amp.pl, line 3

Workarounds

Now that you’ve found the naughty uses of $`, $&, and $`, you need to fix up the code to remove them. If you are using Perl 5.10 or later, use the per-match variables instead (Item 33: Watch out for match variables). If you are using a version earlier than Perl 5.10, you might modify the regular expression to explicitly capture parts of it. The Devel::SawAmpersand documentation gives you these possibilities:

Things to remember

• The match variables $`, $&, and $` suffer performance hits
• You don’t have to use them directly to suffer
• Use Devel::FindAmpersand to trach down their use.

Josh and I will also have a box of signed copies of the book, although those might go fast during the conference (and aren’t part of the course fee). Of course, you can also buy your book in advance and have us sign it during the conference.

There are several reasons to avoid as much low-level work as you can. The foremost reason is that widely-used and heavily-tested libraries have not already made all of the mistakes that you are bound to make, but they’ve almost certainly fixed them. They probably handle all of the edge cases that you don’t even know about, so when your architecture changes, those widely-used modules easily handle the new setup. Is your hand-rolled code to talk to a remote server going to easily handle a proxy or SOCKS setup, or be able to switch from an unencrypted channel to SSL?

Unless you’re the sort of person who likes working in the low-level details, you’re simply wasting your time be reinventing the wheel. If you think your wheel is amazingly better, but you have to remember a lot of people think that. If you have the energy, consider contributing to your enthusiasm to the existing CPAN libraries.

As with everything in The Effective Perl, this isn’t a hard and fast rule. For some things, the higher level libraries don’t give you full access to the protocol, so you do need to work at a lower level.

Enough of that. You may still need some examples. These give you the flavor of what’s available, but that doesn’t mean they are appropriate for your particular situation. As with all modules, use them when they make sense and don’t use them when they don’t.

Simple file downloading

LWP::Simple can handle simple downloads for you:

use LWP::Simple;
my $page = get( 'http://www.perlfoundation.org/' );

That’s simple enough, but what if you need to store that resource somewhere? There’s an app for that:

use LWP::Simple;
getstore( 'http://www.perlfoundation.org/', 'tpf-index.html' );

This also works with FTP and many other protocols. LWP actually handles many other protocols that you might not consider to be part of the World Wide Web. Perhaps you need to fetch some images from a NASA FTP server:

use LWP::Simple;
getstore(
	'ftp://nssdcftp.gsfc.nasa.gov/photo_gallery/hi-res/planetary/moon/gal_moon_color.tiff',
	'awesome-moon.tiff'
	);

Sending email

There are many CPAN modules that can help you send email, and Email::Send is a general interface to many of them. In the constructor, you specify the implementor, in this case, SMTP, and the arguments to the implementor. Email::Send takes care of the rest:

use Email::Send;

my $message = <<'EMAIL';
To: buster@example.com
From: me@example.com
Subject: I'm letting Email::Send send this

I did almost nothing to send this email.
EMAIL

my $sender = Email::Send->new({
	mailer      => 'SMTP',
	mailer_args => [ Host   => 'smtp.example.com' ],
	});

my $rc = $sender->send( $message );
unless( $rc ) {
	warn "Problem sending mail! $rc\n";
	}
else {
	print "Send mail just fine.\n";
	}

Unfortunately, Email::Send is superceded by Email::Simple, but here’s the same program:

use Email::Sender::Simple qw(sendmail);
use Email::Simple;
use Email::Simple::Creator; # an Email::Simple mixin
use Email::Sender::Transport::SMTP;

my $transport = Email::Sender::Transport::SMTP->new({
	host => 'smtp.example.com', # you can also set this in %ENV
	});

my $email = Email::Simple->create(
	header => [
		To      => '"Buster Bean" ',
		From    => '"Mimi Bean" ',
		Subject => "Thanks for all the fish",
	],

	body => "I'm sending this with Email::Simple.\n",
	);

my $rc = eval { sendmail(
	$email,
	{ transport => $transport }
	) };

unless( $rc ) {
	warn "Problem sending mail! $@\n";
	}
else {
	print "Send mail just fine.\n";
	}

This “simpler” version is under active development, but it goes against most of the points we want to stress: you shouldn’t have to think about what most of this is doing or how email actually works, just like you don’t have to understand internal combustion to drive a car.

Programmatic control of a web browser

LWP is sufficient for simple web tasks, but when you have to interact with forms, click through several pages, and handle other actions you might expect from an interactive browser, WWW::Mechanize is the tool you should you. It tracks your path through a website, handles cookies, and lets you select and follow links.

Here’s an example that takes a module name, a starting line number, and an ending line number. It goes through these steps:

• queries CPAN Search for the module,
• finds the right link in the search results

• follows the module link
• looks for the “Source” link on that page
• gets the content of that page
• extract that line range

use WWW::Mechanize;

my( $module, $start_line, $end_line ) = @ARGV;
print "Looking for $module lines $start_line to $end_line\n";

my $mech = WWW::Mechanize->new;

$mech->get( 'http://search.cpan.org' );

$mech->submit_form(
	form_number => 1,
	fields      => {
		query   => $module,
		mode    => 'module',
		}
	);

my $module_links_ref = $mech->find_link( text => $module )
	or die "Did not find $module link\n";
$mech->get( $module_links_ref->[0] );

$mech->follow_link( text_regex => qr/\ASource\z/ )

my $content = $mech->content;

open my( $fh ), '<', \ $content;

while( <$fh> ) {
	next unless $. == $start_line .. $. == $end_line;
	printf "%d: %s", $., $_;
	}

You can run this program to get an extract of some lines from HTTP::Size:

$ perl mech HTTP::Size 10 20
Looking for HTTP::Size lines 10 to 20
10:
11: =head1 SYNOPSIS
12:
13:     use HTTP::Size
14:
15:     my $size = HTTP::Size::get_size( $url );
16:
17:     if( defined $size )
18:             {
19:             print "$url size was $size";
20:             }

This is only a small taste of the sorts of things that WWW::Mechanize can do.

Downloading new files from an FTP server

Sometimes you need to use a lower-level interface. For instance, if you want to sync a local directory with a remote FTP directory, you can use Net::FTP to connect to the remote directory, get the list of files in that directory, compare the modification time of the local file with the modification time, and download files that are newer on the remote side:

use Net::FTP;

my $host = 'nssdcftp.gsfc.nasa.gov';

my $ftp = Net::FTP->new( $host, Debug => 0 )
	or die "Cannot connect to $host: $@";

$ftp->login("anonymous",'-anonymous@')
	or die "Cannot login: ", $ftp->message;

$ftp->cwd( '/photo_gallery/hi-res/planetary/moon' );

foreach my $file ( $ftp->ls ) {
	if( (stat($file))[9] < $ftp->mdtm( $file )  ) {
		print "Fetching $file...\n";
		$ftp->get( $file );
		}
	else {
		print "$file up-to-date\n";
		}

	}

In this case, the Net::FTP module is the appropriate level of coding. You don’t have to deal with the FTP protocol directly, but you have enough flexibility to deal with the features that the protocol provides.

Low-level sockets

Perl has the built-in interface so you can minutely control TCP and UDP sockets if that’s what you need to do. However, since we’re trying to convince you not to do that, we’ll leave those bits as an exercise for the reader.

Things to remember

• Work at the highest level possible and reasonable
• Use one of the popular CPAN modules instead of reinventing your own.
• Don’t create your own low-level implementations

Before you get too far, take a look at Devel::REPL, which Carp::REPL is based on. It’s a basic Read-Evaluate-Print Loop for Perl. You enter a line of Perl then the REPL evaluates it and prints the result.

You can start the REPL from the command line:

perl -MDevel::REPL -e 'Devel::REPL->new->run'

Devel::REPL also installs an re.pl that you can use, but it’s not too hard to write your own, especially if you’d like to remind yourself how to get out of the REPL:

use Devel::REPL;

print "Starting a Devel::REPL setting. Type exit to stop\n";

my $repl = Devel::REPL->new;
$repl->load_plugin($_) for qw(History LexEnv MultiLine::PPI);
$repl->run;

Run repl and try some Perl expressions. Notice that you get both the output from print or say as well as the result of the print or say (normally 1):

Starting a Devel::REPL setting. Type exit to stop
$ my $string = 'The Effective Perler'
The Effective Perler
$ say $string
The Effective Perler
1
$ substr( $string, 9, 4 )
tive
$ substr( $string, 14, 4 )
Perl
$ $$
66461
$ $string =~ /Perl/
1
$ $string =~ /Ruby/
$ $string =~ /(P\S+)/
Perler
$ $string
The Effective Perler
$ localtime
16 32 2 16 4 110 0 135 1
$ time
1273995160
$ use List::Util qw(sum)
$ sum( 1 .. 1000 )
500500
$ my $sub = sub {
> my $x = shift;
> print $x*2;
> }
CODE(0xa66990)
$ $sub->(4)
8
1

That’s nice to try out some short Perl code and isolated expressions, but you’d like to be able to do that somewhere in the middle of a big program. That’s where Carp::REPL comes in. It installs a DIE handler that invokes Devel::REPL.

Here’s a small script that sometimes dies, and although Perl tells you why, pretend that it doesn’t:

#!/Users/brian/bin/perl5.10.1

use 5.010;

my( $arg1, $arg2 ) = @ARGV;

my $quotient = divide( $arg1, $arg2 );

say "quotient is $quotient";

sub divide { $_[0] / $_[1] }

Here’s a couple of runs:

$ perl divide 1 2
quotient is 0.5
$ perl divide 1 0
Illegal division by zero at divide.pl line 7.

To track down the error, load Carp::REPL from the command line and run the program. Instead of killing the program, the runtime error triggers an interactive shell so you can explore the problem:

$ perl -MCarp::REPL divide.pl 1 0
Illegal division by zero at divide.pl line 11.

Trace begun at divide.pl line 11
main::divide(1, 0) called at divide.pl line 7
$

Okay, so what now? You’re at line 7, but what is that? Look around with :l:

$ :l
  6:
  7: my $quotient = divide( $arg1, $arg2 );
  8:
  9: say "quotient is $quotient";
 10:
*11: sub divide { $_[0] / $_[1] }

Once you see that line 11 is the division, and you need to handle that better. You can redefine divide (the result is the subroutine definition *main::divide) and try again using the same arguments:

$  *divide = sub { eval { $_[0] / $_[1] } // 'NaN' }
Subroutine main::divide redefined at (eval 266) line 21,  line 6.
*main::divide
$ divide( $arg1, $arg2 )
NaN

Now divide works! Since Carp::REPL comes in as your program is already die-ing, you don’t have a chance to pick up where you left off unless your code is already set up to recover from a die, such as with an eval block.

There’s a lot more that you can do with Carp::REPL. You can set a warn handler instead so you can drop into the REPL when your program emits a warning:

$ perl -MCarp::REPL=warn some_program

You can also debug your test files by dropping into the REPL when a test fails:

$ perl -Mblib -MCarp::REPL=test t/test.t

Besides the very basics that you see here, Carp::REPL can do much more through its various plugins. If you don’t find a plugin that you like, you can write your own.

The benefit of a scalar reference comes when you realize that perl is stack-based. That is, when it wants to pass things to a subroutine, it puts things on a stack and calls the subroutine. The subroutine takes the right number of things off the stack, does its processing, and puts its return values on the stack. The caller takes the return values off the stack and the program continues. Moving those data onto and off the stack can involve quite a bit of copying.

When you call a subroutine, perl really only puts pointers to the data on the stack. These aren’t pointers in the C sense, but we use the word to distinguish it from Perl’s specialized definition of “reference”. It’s not until you want to assign the values to variables that perl has to copy the original data to initialize the new variables. This lazy initialization is a performance optimization perl uses to avoid copying data it doesn’t need to. When you unpack your argument list into variables, you copy the data into the variable.

Here’s a sequence of events that shows that you make several copies of the same data when you pass a string as an argument, store it in a temporary variable, and then return the unchanged string. This example uses a short string of abc replicated 10 times, but imagine this to be a large XML document or something similarly daunting:

use Devel::Peek;
use 5.010;

my $old_version = 'abc' x 10;
say Dump( $old_version );

my $new_version = copy_string( $old_version );
say Dump( $new_version );

sub copy_string {
	my( $copy ) = @_;
	say Dump( $copy );
	$copy;
	}

The output shows that you made three different copies of the same data, one each for the original, the temporary variable in the subroutine, and the return value. It’s the address after PV = and right before the string that shows the location of the data (rather than the location of the variable). In this case, those addresses are 0x219490, 0x2194b0, and 0x219430:

SV = PV(0x801080) at 0x80f680
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x219490 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x801028) at 0x81b3d0
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x2194b0 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x8015f8) at 0x80f670
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x219430 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

There’s a way, not necessarily a best practice, that people use to get around that first copy. When you use @_ directly, you use and affect the original data because you actually use the original data instead of a copy of it. That’s why you sometimes see people use it directly in subroutines to change data in place:

use Devel::Peek;
use 5.010;

my $old_version = 'abc' x 10;
say Dump( $old_version );

my $new_version = copy_string( $old_version );
say Dump( $new_version );

sub copy_string {
	say Dump( $_[0] );
	$_[0];
	}

However, since copy_string modifies its argument in-place, you don’t need the return value.

use Devel::Peek;
use 5.010;

my $old_version = 'abc' x 10;
say Dump( $old_version );

copy_string( $old_version );

sub copy_string {
	say Dump( $_[0] );
	$_[0];
	}

Now the output shows that $old_version and $_[0] are the same data (just not equivalent strings). Notice that the address of the two variables (0x801080 in this case) are the same. That’s the special aliasing magic:

SV = PV(0x801080) at 0x80f680
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x219440 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x801080) at 0x80f680
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x219440 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

Using @_ directly might be fine for very light jobs, but what if the argument list is more complicated? You don’t want track the position of the argument in @_.

Instead, you use a scalar reference. The argument list contains a real Perl reference, so you aren’t copying anything other than the connection to the data.
You can store the reference value in a named variable without making a copy of the end values:

use Devel::Peek;
use 5.010;

my $old_version = 'abc' x 10;
say Dump( $old_version );

my $new_version = copy_string( \$old_version );

sub copy_string {
	my( $ref ) = @_;
	say Dump( $$ref ); # deref to see data, not ref to it
	}

The output shows essentially the same effect as using @_ directly:

SV = PV(0x801080) at 0x80f680
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x2042f0 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x801080) at 0x80f680
  REFCNT = 3
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x2042f0 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

The advantage with a reference is that you won’t unintentionally make a copy when you store the value in a variable. Say, for instance, that you need to call another subroutine and pass along one of the arguments, and that second subroutine store it in a temporary variable:

use Devel::Peek;
use 5.010;

my $old_version = 'abc' x 10;
say Dump( $old_version );

copy_string( $old_version );

sub copy_string {
	say Dump( $_[0] );
	another_sub( $_[0] );
	}

sub another_sub {
	my( $string ) = @_;
	say Dump( $string );
	}

Now you’ve made a copy of the data in another_sub:

SV = PV(0x801080) at 0x80f680
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x21d250 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x801080) at 0x80f680
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x21d250 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x801028) at 0x81b4e0
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x204340 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

If you passed along references instead, it’s always the same reference so there’s no danger of creating another copy:

use Devel::Peek;
use 5.010;

my $old_version = 'abc' x 10;
say Dump( $old_version );

copy_string( \ $old_version );

sub copy_string {
	my( $ref ) = @_;
	say Dump( $$ref );
	another_sub( $ref );
	}

sub another_sub {
	my( $ref ) = @_;
	say Dump( $$ref );
	}

The output shows only one copy, even though you used two different temporary variables:

SV = PV(0x801080) at 0x80f680
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x219350 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x801080) at 0x80f680
  REFCNT = 3
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x219350 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x801080) at 0x80f680
  REFCNT = 4
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x219350 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

Things to remember

• perl makes copies of data when you assign it to different variables.
• Pass scalar references as arguments to avoid unnecessary string duplications.
• You can modify variables in-place through references.