http://www.perlmonks.org?node_id=1024355

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

I'm trying to install cpanm in /usr/bin (using the normal wget -O- http://cpanmin.us | /usr/bin/perl - App::cpanminus). However on one server it keeps getting put in /usr/local/bin.

Apparently it uses the value in perl -V:installsitebin which is different on this one server. So how do I change this value? I'm not totally sure i care if it is a temporary or permanent change.

And yes I know I could download the standalone executable, but I don't want to do that. All my other servers have just worked, I want to get this one to do the same.

Replies are listed 'Best First'.
Re: changing vaules in perl -V
by syphilis (Archbishop) on Mar 19, 2013 at 23:22 UTC
    Here's a perlish approach as per the way that Mattia Barbon's ExtUtils::FakeConfig achieves the result:
    1) Create a Config_m.pm that contains:
    package Config_m; use warnings; use Config; my $tied = tied %Config; $tied->{installsitebin} = '/usr/bin'; 1;
    2) Set the PERL5OPT environment variable to -MConfig_m

    With the perl5opt environment variable unset, 'perl -V:installsitebin' (and $Config{installsitebin}) still return their original value.
    But, when perl5opt is set correctly, 'perl -V:installsitebin' (and $Config{installsitebin}) will return the new value.

    Here's a Windows demo (where PERL5OPT is initially unset):
    C:\_32\pscrpt>type Config_m.pm package Config_m; use warnings; use Config; my $tied = tied %Config; $tied->{installsitebin} = '/usr/bin'; 1; C:\_32\pscrpt>perl -V:installsitebin installsitebin='c:\MinGW\perl512\bin'; C:\_32\pscrpt>set PERL5OPT=-MConfig_m C:\_32\pscrpt>perl -V:installsitebin installsitebin='/usr/bin'; C:\_32\pscrpt>
    One potential annoyance with setting the perl5opt environment variable system-wide is that every perl on the system needs to be able to load a Config_m.pm.

    Cheers,
    Rob

      This is definitely along the lines of what I want to do.

      I put the Config_m.pm file in ~/perl_libs, removed everything I could find related to cpanm, and changed my install line to be:

      wget -O- http://cpanmin.us | /usr/bin/perl -I /home/xorl/perl_libs -MC +onfig_m - App::cpanminus -f
      (-f to force a reinstall)

      Unfortunately it is still installing in the wrong place.

      /usr/bin/perl -I /home/xorl/perl_libs -MConfig_m -MConfig -e 'print $Config{"installsitebin"} . "\n";' gives the "correct" value (/usr/bin). So I'm not sure what is going on at this point.

Re: changing vaules in perl -V
by ikegami (Patriarch) on Mar 19, 2013 at 19:08 UTC

    That value is set when perl is Configured as part of its installation process. You'll have to rebuild Perl to change it.

    You can override most if not every path when you install a module. But in this case, the solution is much simpler:

    mv /usr/local/bin/cpanm /usr/bin/
    or
    ln -s /usr/local/bin/cpanm /usr/bin/
Re: changing vaules in perl -V
by sundialsvc4 (Abbot) on Mar 19, 2013 at 19:10 UTC

    IIRC, the install-location used by cpanm (or cpan) is configured separately from the way that Perl itself knows where to look for libraries.   Still, if one server is “the odd man out,” there could be several problems ... maybe just one source?

    The most common determinant of the Perl search-path (perl -V) is the PERL5LIB environment variable, which is ordinarily set by a hidden script such as .bashrc on a Linux box; or by a registry setting on Windows.   (I believe the System control-panel ... it’s per-user and/or global ... but don’t quote me.)   Perhaps this file / registry entries are missing or different on this machine; perhaps they’re not being executed.

    Free-thinking now ... if the root problem is that a script isn’t being executed such that environment-variables aren’t being set ... perhaps several of them aren’t being set ... which could explain many things simultaneously.   Especially since, in the case of Unix/Linux, the file that contains these settings is usually hidden and not-required, its mere absence could manage much mischief.