tphyahoo has asked for the wisdom of the Perl Monks concerning the following question: 

use strict;
use warnings;
use CPAN;
for ( 'Catalyst::Plugin::Authentication' ) { install ($_)} #doesn't wo
+rk
#for my $mod ( 'Catalyst::Plugin::Authentication' ) { install ($mod)} 
+#works

[download]
The error I get with the $_ variant happens at the write makefile step: 

... blah blah blah...

Removing previously used /home/thartman/.cpan/build/Catalyst-Plugin-Au
+thentication-0.09

  CPAN.pm: Going to build N/NU/NUFFIN/Catalyst-Plugin-Authentication-0
+.09.tar.gz

Checking if your kit is complete...
Looks good
Writing Makefile for Catalyst::Plugin::Authentication
Modification of a read-only value attempted at /home/thartman/perlroot
+/perl/lib/5.8.8/CPAN.pm line 4676.

[download]

I don't understand why my $var works, but $_ from the loop doesn't. I thought $_ was automatically lexically scoped, and could be relied on to do the same thing as specifying my $var before the for list. What gives?

By the way, to test this, I had my perl root directory tarred up. Before running the script I reverted my perl root directory by 

thartman@nbartertest:~/nbarter$ cat ~/perlroot-revert
#!/bin/bash
rm -rf perlroot
tar -xzvf perlroot.tar.gz

[download]
Then I ran perl -e 'use Catalyst::Plugin::Authentication'

to confirm that this produced an error because of the missing module, and then I would run the script to see if things installed ok or not.

Also, there's nothing special about Catalyst::Plugin::Authentication. This error seems to be produced regardless of what module I try to install.

Blessings to the monastery.

Replies are listed 'Best First'.
Re: cpan install($_) doesn't work in loop, but normal lexical var does
by imp (Priest) on Aug 27, 2006 at 16:54 UTC
    This is happening because somewhere in the install process an unlocalized $_ is being assigned to.

    The same error will occur with the following: 

    for ( "a" ) { 
  $_ = 1;
}

# Or
for ( "a" ) { 
  while (<>){
  }
}

    [download]

    The magic of $_ is too fragile for anything but simple cases in my opinion. Do this instead: 

    for my $module ('Catalyst::Plugin::Authentication') {
}

    [download]
[reply]
[d/l]
[select]

      Is your ExtUtils::MakeMaker older than 6.18? parse_version used to blow away an existing $_. (I just discovered that this morning, in fact.)

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
[d/l]
[select]
      The magic of $_ is too fragile for anything but simple cases in my opinion.
      Yes, but it's the authors of CPAN modules that should be watching out for this, not the users of the modules.

      Something I've wondered about off-and-on: is there any compelling reason not to do a "local $_;" at the beginning of every subroutine, unless you're relying on a value being passed in via $_? Why isn't this one of our "best practices"?

[reply]

        "...is there any compelling reason not to do a "local $_;" at the beginning of every subroutine?"

        Yes, doesn't fix the problem. Any time you call a function, subroutine or method it could blow away $_. And you will never have control of other peoples code so if you rely on $_ not being hosed you'll eventually get burnt. Far better is to practice defensive programing and not rely on $_ after all the perl syntax in all cases allows you to specify something other that the default input/output scalar.

        s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s |-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,, $|=1,select$,,$,,$,,1e-1;print;redo}
[reply]
[d/l]

Back to Seekers of Perl Wisdom