brian d foy

I didn't break them myself, but the Perl Power Tools project that I revitalized did. Well, that's not even strictly true. The Perl Power Tools, which install thin implementations of common Unix tools, highlighted a problem with the idea of tools such as plenv.

For awhile perlbrew was a really hot idea. It downloads, compiles, and installs completely separate perls for you. When you want to make a particular perl the default, you run a command and symlinks are shuffled around. I never particularly liked the tool because I use several versions of Perl at the same time so I don't rely of what I might find in the PATH environment variable and what that symlink might point to. Changing symlinks affects the entire system and every other session. This is also the reason that #!/bin/env perl doesn't work for me. It always finds the first perl, which is not the one I usually want.

The plenv idea is a little different. You set environment variables and shim versions of the programs you actually want figure out where to look for the real programs of the same name. This only affects your session, which is a big improvement. I first encountered this idea through Mac OS X, but in a slightly different form. That system perl is actually two perls in one file. You play with VERSIONER_PERL_VERSION and some other environment variables and the system selects the right thing. Since I don't use the system perl, I haven't played with this in awhile, though. Try a strings on the perl file on Mac OS X and you should see stuff from two different versions. Someone can probably explain it better than me; I've never cared to investigate it.

And here's where Perl Power Tools highlighted a problem. plenv makes shims for things in the *path-to-perl*/bin directly. That's where you'll find cpan, cpanm, and your other favorite perl tools. plenv, a bash script, used common unix tools, such as head, to do its work. But, Perl Power Tools has its own head, which plenv sees and creates a shim for. That shim version calls plenv to see where head is, but it needs head to do that. Fork bomb. Drop the mic.

This beaks even if the Perl Power Tools version of head worked correctly, as I see it, because the fork bomb happens as it tries to find head. See GitHub issue #443 for cpanm or GitHub issue #78 for plenv.

But then that's the problem with assuming you know where something is (or that it is what it says on the tin). If I can install my own perl and put anything I like in there, or do something to fool you into installing anything I like in there (such as installing a module), I can change what happens on your system. It's a security issue I discuss in Mastering Perl. If you allow system to look through the PATH, you might not get what you expected. That's why taint checking cares so much about insecure paths and only accepts very particular paths in that environment variable. But, I also show in Mastering Perl how to defeat taint checking by doing the same thing with a fake perl.

Still, Perl Power Tools probably shouldn't drop stuff into something you already have in PATH (GitHub issue #19). They are really a tool of last resort that you should have to apply with a bit more consideration. They can be in their own directory and you can add that directory to PATH yourself, most likely at the end of PATH. That's something I can fix.

I can't fix the idea of plenv (or perlbrew). If it works for you, that has nothing to do with me. It was too much magic for me, even though in idle moments I keep thinking about how to write my own version (say, call it like myperl -v5.20 arg arg arg). The fix in plenv creates the unix utilities it needs in own shell code.

But, in all of this, there's some really cool things going on in Perl. The tools are getting more interesting, new ideas are getting out there, and when things happen, we all work it out. :)