Second printing available

Intermediate Perl 2nd edition’s second printing is now available. This contains fixes for almost all of the reported errata, but it otherwise the same content.

If you’ve bought your ebook through O’Reilly, you should have it available in your O’Reilly account. Look at your O’Reilly products list. I have the Alpaca under mine and I can immediately download the format I want or send them to Dropbox.

The Alpaca gets a second printing

Most tech books have trouble selling even a couple thousand copies, which makes it tough for a publisher to figure out how many to print at first. Print too many and they’ll just sit there, or worse. The publishing industry is a bitch because the book shops can returned unsold inventory and get money back. On every royalty statement, I have a “reserve withheld” and a “reserve returned”. The publisher reserves some of my royalty in case the book stores return books. After a certain period, they return that. But, they then withhold more. That’s just the way it is.

A second printing means that people are buying the book, enough so that the publisher will commit a bunch of money to create a couple of palettes of books that they’ll send to the distributor and that the distributor will send out to shops.

Before they do that, though, they give the authors a chance to fix small problems—typos and the like. Despite the number of people who look at the book before the first printing, things slip through the cracks. We can’t change major things in the book. That makes the second printing the .1 release, slightly better than the .0 release.

That means that one of the authors goes through all of the errata. André Philipp has done a tremendous job tracking down more problems than I thought a book could ever have, which makes it better for everyone else.

I don’t know when the second printing will actually show up. Even when it’s available, copies of the first printing may still be on the shelves waiting to be sold. You can tell which version you have by looking at the printing history on the data page.

Clarifying local::lib and cpan in Chapter 2

local::lib is highlighted in Intermediate Perl when I go through the CPAN tools in Chapter 2. Each of the tools has a slightly different set of features and I try to steal the good one. I added a local::lib to cpan so you can add the local::lib defaults for a one-shot installation process. This steals a feature from cpanm which has a --local-lib option:

% cpan -I Dancer

This version of cpan comes with v5.14, but you can always get the latest by installing App::Cpan.

André Philipp, who’s been submitted good corrections to Intermediate Perl, noticed a weird usage pattern. He did what local::lib suggested by setting the environment variables for his session:

export PERL_MB_OPT='--install_base /home/amelia/perl5'
export PERL_MM_OPT='INSTALL_BASE=/home/amelia/perl5'
export PERL5LIB='/home/amelia/perl5/lib/perl5/i386-linux:/home/amelia/perl5/lib/perl5'
export PATH="/home/amelia/perl5/bin:$PATH"

As session settings, cpan picks up and respects those. Actually, cpan doesn’t care about any of them, but the things it starts, such as Module::Build, do. There’s not much magic to local::lib; it merely sets environment variables.

Since André had set these, cpan‘s -I switch didn’t seem to do anything because he was always installing into the local::lib directories. The tools don’t care who set the environment variables as long as they are set.

If I always want to install into the local::lib directories, the session settings are fine and that’s what I should do. I, however, don’t always want to do that. In fact, I almost never want to do that. I added the -I switch for one off use assuming that I hadn’t set anything else to trigger local::lib.

The trick, then, is to manage expectations. If I map the various things a person might configure and how those interact, I found out that my -I feature might have some problems. What if I set the environment and use -I at the same time?

I’ve colored one endpoint red because I don’t know what happens there. It depends on what local::lib will do. People don’t care about that those. They have expectations about the interface. Someone used to unix tools will expect the closer settings will override distant ones. A tool will use command-line settings over environment over configuration files. That is, more transient settings override more permanent ones.

What does local::lib do in that case? I start by merely loading the module and doing nothing else. In that case, local::lib prints its settings:

% perl5.14.2 -Mlocal::lib
Attempting to create directory /Users/brian/perl5
export PERL_LOCAL_LIB_ROOT="/Users/brian/perl5";
export PERL_MB_OPT="--install_base /Users/brian/perl5";
export PERL_MM_OPT="INSTALL_BASE=/Users/brian/perl5";
export PERL5LIB="/Users/brian/perl5/lib/perl5/darwin-2level:/Users/brian/perl5/lib/perl5";
export PATH="/Users/brian/perl5/bin:$PATH";

What happens if I fool with the PERL_MM_OPT? local::lib replaces the environment variable, in all cases:

% export PERL_MM_OPT=/env/setting/perlmmopt
% perl5.14.2 -Mlocal::lib -E 'say $ENV{PERL_MM_OPT}'
% perl5.14.2 -Mlocal::lib=~brian -E 'say $ENV{PERL_MM_OPT}'

I don’t know if anyone expects this. I would have expected local::lib to use default settings already specified in the environment. The documentation doesn’t say which way it will go, although it says “On import, local::lib sets the following environment variables to appropriate values”. It doesn’t say what appropriate values are or that it replaces existing values with new ones.

There’s no reason I should really expect that, and that’s the problem with expectations. People expect different things because they have different assumptions and starting points, even if they don’t think they do. When I added that feature to cpan, I assumed it would be straightforward. I had my own assumptions, despite being the person (the author) who’s supposed to make all of that apparent.

I don’t think that local::lib is doing anything wrong. If it did it some other way, a different group of people would be confused because they would assume something else. There’s really no way to win. The best any interface can do is make it suck less.

Answers for O’Reilly PR

The O’Reilly public relations people asked me to answer some questions about the new Intermediate Perl so they can prepare materials for reviewers and the press. As a reader of this website, however, you get the answers before they do, and you get my full answers, which might show up as edited excerpts in O’Reilly’s materials.

1. What has changed with this new edition?

In the previous editions of Intermediate Perl, we covered packages, references, objects, modules, testing, and finally distributions. We built up from the small things to finally create a distribution. That’s not how people work, though, so we changed things around.

We covered references, which are much more useful than just objects. That’s the first third of the book. Then we cover packages as a prelude to the big change for this edition. We then move immediately into creating a distribution. We show readers where they’ll end up before we show them how they’ll get there. This is how developers actually work—they create the distribution then modify it. This provides us a framework for introducing each new concept. For instance, we can cover testing and quality control as we go along instead of segregating it in a chapter at the end of the book. Readers pick up these topics slowly and steadily as they move along.

2. What updates were enacted?

As with all Perl book updates, we’ve fast-forwarded the content to latest version of Perl using modern style and usage for examples. That’s just the small potatoes though.

We’ve also expanded coverage of subroutine and regular expression references.

3. What will excite long-term Perl fans the most?

Perl has it’s own built in object system, but some developers are using a layer on top of that. Moose, a post-modern object system, deserves a book of its own. We didn’t want to write that book for Intermediate Perl, so we included a chapter to introduce Moose.

We’ve created a web site devoted to this book, at We have a downloads section that supports the exercises (and answers) as well as interact with our audience.

4. What will cause reviewers to rupture organs in their haste to review?

We’ve distributed five golden tickets among the books we’re distributing to almost 1,000 reviewers. Each bearer of a golden ticket gets an all-expenses paid one-day visit to Damian Conway’s Amazing Top Ten in Alice Springs, Australia. During the day, they will interact with the ten deadliest species of snakes in world, five of which are native to Australia. At night, they’ll encounter ten of the most dangerous regular expressions, five of which are also native to Australia. Survivors can also box with kangaroos, chew eucalyptus with koalas, and pilot bottomless canoes before they leave. We’re pleased that Damian wrote the foreword to our book and has allowed us to provide this experience to our reviewers.

Get 50% off Perl ebooks, including Intermediate Perl

You can buy Intermediate Perl now, directly from O’Reilly in ebook form. For the next week, you can buy it for 50% off using discount code WKPER5.

50% off

Every ebook from O’Reilly is DRM free and come in PDF, ePub, and Mobi formats. If you’ve authorized O’Reilly’s Dropbox app, once you’ll purchase the books they’ll sync to your Dropbox account (in ~/Dropbox/Apps/O’Reilly Media). You can read them on any device anywhere you are.

The print version is still making its way out of the printers and to distributors, but we expect it to show up in the next three weeks.

Intermediate Perl is available for pre-order

You can now buy Intermediate Perl. I’ve just submitted the final changes and the final publishing bits should finish this week, sending the result to the printers very soon. The book should ship before the end of August.

If I haven’t listed your favorite bookseller, send a link.

Syntax coloring in Intermediate Perl PDF

O’Reilly wants to try an experiment with the Intermediate Perl PDF. We’re not limited by the physical process of putting ink on paper (and it’s a bit expensive to have more than one color of ink). I’m just going to show you the images and let you tell me what you think.

Page 25

Page 60

Page 104

Page 190

Page 210

Fixing bugs instead of explaining them

David Golden, one of the reviewers for Intermediate Perl, gave me extensive comments about one of the test program examples in the book. I made a simple example using Test::Output, a module I sometimes use but didn’t write. It solved my needs at the time, but it has some issues. Perl’s output is complicated, and the simple tie in Test::Output::Tie doesn’t cover all the cases.

I’m the current maintainer of the module, and rather than explain the edge cases in my example (or fix the module), I merely mentioned to David that we should reimplement Test::Output with Capture:Tiny, his module that handles almost all cases. I meant “we” in the universal sense, and I didn’t say much because I was busy writing the book. A couple of hours later, David sends me a pull request.

That often happens as part of the writing process. If something is too hard to explain, it’s probably too hard to use. The time explaining it is better spent making it clear, unbuggy, or whatever it takes to avoid the explanation. In this case, it’s even better when someone else did it.

The Alpaca is on its way

O’Reilly now has Intermediate Perl, Second Edition. Just this morning, in time for the open of business on the East Coast, I finished fixing the final reviewer comments. I went through over 300 pages of extensive comments:

320 pages of this, from three different reviewers

This doesn’t mean that the book is done. The publisher does their bit with indexers, proofreaders, and the authors checking the book again. There’s usually a few things to fix after that, and, once, fixed, the books go to the printers. The printers send it to the distributors, who send it to the sellers. After all of this, we should have the actual bound paper version around July, but probably not in time for you to walk away from OSCON holding one.

The book isn’t available for pre-order yet, but O’Reilly should add it to their Rough Cuts early editions program so you can see it sooner than the printers. It’s available for pre-order from the O’Reilly site, but I haven’t seen it available anywhere else yet. We’re working on that.

Multiple package VERSION declarations

I’m re-reading the parts of Intermediate Perl where we introduce packages. Perl v5.12 introduced an expanded package syntax to include a version and a block:

package Foo { ... }
package Foo 1.23;
package Foo 1.23 { ... }

That almost seems to imply that you’d have to completely define the package inside the block if you use a block, but as you know from everything else you’ve experienced in the language, Perl is happy to let you muck with other things. You can add to the package later:

use v5.12;
use warnings;
package Foo { ... }
package Foo { ... }

The next package declaration does not replace the previous one, although what you do in the block might redefine subroutines or change variable values.

I was curious what happens when I use different versions with multiple package statements:

use v5.12;
use warnings;

package Foo 1.23 {
	sub foo123 {
		say "I'm in ", Foo->VERSION;

package Foo 1.22 {
	sub foo122 {
		say "I'm in ", Foo->VERSION;

package Foo {
	sub foo {
		say "I'm in ", Foo->VERSION;

package Foo;


Perhaps unsurprisingly, the last one wins:

I'm in 1.22
I'm in 1.22
I'm in 1.22

The new syntax is really just a shortcut for setting the package $VERSION. The last value it gets is the value it keeps, just like any other variable. It might be nice to have a warning for a version mismatch, but practically, there’s not much we can do with the version. We can’t, for instance, define several, separate versions of the package in the code application then decide which one to load later (or even load multiple separate versions).