Randy Stauner

I wanted to comment on kevin spencer's perlbrew intro but my blabbering grew so long I chose to make a separate post instead.

shebangs

I used to use the #!/usr/bin/env perl trick for shebangs until (when reading about packaging executables with dists) I learned that ExtUtils::MakeMaker (and Module::Build) will automatically rewrite a full-path shebang to point to the interpreter used during install, but it specifically does not do this with the env trick.

I inadvertently combined 'env perl' with local::lib once and found that the script (reachable from my local::lib bin/) would die because I was trying to run a script in my path with a perl that didn't have that module installed (I must have switched perls in the meantime).

If the perl that installed the module is embedded in the script then calling it from the command line makes sure that it will be run by a perl that has the module installed (and has the same version that corresponds to the script using it). So it seems better to me to use the full path and let EUMM rewrite it.

tl;dr: use perlbrew alias to denote "current" version

I typically use one perl as my main perl and use a perlbrew alias to point to it:

perlbrew alias create perl-5.14.1 local

Then I can use

#!/home/rando/perl5/perlbrew/perls/local/bin/perl

for the shebang in all of my scripts.

Yeah, it's a little long, but I tab complete it or dump an env var rather than typing it out. This way any scripts that are part of dists I release will get rewritten by EUMM upon install and any scripts that are just for my personal use work with my "current" favorite perl.

When 5.14.2 is released I will install it, reinstall the modules I use, and change my perlbrew alias to point to it.

Sometimes I also symlink /usr/local/bin/perl to my perlbrew alias if I'm the only one on the machine or if perlbrew is in a location that is available to everyone (like /opt).

Then you can use the very common

#!/usr/local/bin/perl

which is shorter and easier to remember.

perlbrew and cpan modules

As a side note I do a perlbrew switch and use the cpan client to install modules directly into the perl lib dir (with the default installdirs site option) and I only use local::lib if I need to test a module with my system-provided perl.

That way (with modules installed relative to the perl that installed them) when you perlbrew switch if you haven't installed a module it's script won't even be found in your path.

If anyone has any points of contention or better suggestions, please share.

I'm interested in maintaining Text::VimColor authored by Geoff Richards (GEOFFR).

Does anybody know Geoff?

He hasn't uploaded to CPAN since 2006.

I emailed him a few months ago (using 3 different addresses from his CPAN page) but never heard back.

I asked on IRC and it sounded like a couple of guys knew him but hadn't heard from him in a long time.

So this is my last attempt before emailing the module list and asking for comaint status.

Thanks!

Ran into an issue today and wanted to share in case anybody else hits the problem.

Using the good-old cpan client I found myself unable to install a module. It took me a while to track down the problem...

I had CPAN::SQLite installed and that appears to have a bug (which I filed as RT 69415):

If a greater version of a dist is removed from the CPAN, CPAN::SQLite will fail to reindex the "current" (lesser) version, which means the cpan client will spiral into a 404 loop and give up.

So if you try to install a module and cpan spews 404 errors for a different version than you're expecting, open up ~/.cpan/cpandb.sql with sqlite3 and delete that record with something like:

DELETE FROM dists WHERE dist_name = '?'

My previous post about a weird do-block bug I stumbled upon has been fixed as of 7c2d9d0, the day after I posted. I don't know if anybody saw this post or if it was a coincidence, but thanks!

I love the comment:

Fix context propagation below return()

A.k.a. "RT #38809 strikes back".

UPDATE: This perl bug has been fixed

I was writing some very simple unit tests last night and was baffled when one didn't work. The code was very simple, something I thought I had done hundreds of times:

return do { local $/; $fh->getline }

But I stumbled upon some weird voodoo... It's extra baffling to me considering this recent post/bug discovery by Brian D Foy.

It's not the same thing, but it seems similar to me. Unfortunately the commit that fixed Brian's bug 93548 does not fix this one.

I refactored the problem down to a pretty small sub, and am further baffled by the minor variations that cause the problem to go away.

Here is the script and the output from various perls... Interestingly this test appears to include another bug that was fixed somewhere between 5.10 and 5.12...

Can anybody make sense of this? Am I missing something? Or is this a legitimate perl bug?

UPDATE: I should add that, in my original function, I added a warning to the getline method on the object so that I could tell that it was in fact getting called (inside the do-block), but somehow undef was still being returned in the end.