You're right, and you can be sure about it. When you run /usr/bin/perl -V you'll see the directories that will be affected by installing modules via /usr/bin/perl -MCPAN -e shell

Likewise, when you run /opt/apps/perl/perl5220/bin/perl -V you'll see the directories that are affected when you run CPAN via this instance of perl.

  PERL_MB_OPT='--install_base /home/username/perl5'; export PERL_MB_OP
+T;
  PERL_MM_OPT='INSTALL_BASE=/home/username/perl5'; export PERL_MM_OPT;
  PERL5LIB="/home/username/perl5/lib/perl5"; export PERL5LIB;
[download]

But will that not mess up any updates you (later) need to make to the system Perl?

Or worse, the system Perl will start using the local perl modules which may be incompatible between the versions of local and system Perl?

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

My blog: Imperial Deltronics

But will that not mess up any updates you (later) need to make to the system Perl? Or worse, the system Perl will start using the local perl modules which may be incompatible between the versions of local and system Perl?

Thats a good question :)

I don't think you can mess up the system perl

any installs would be done as root and root ought to have a different %ENV :)

but if root doesn't, then the system installs just go in a different directory

now that might cause something tricky to happen, but if you're using system tools to update the system perl, then those tools should remove PERL_ vars from the equation

But yeah, the possibility exists, maybe :D

However , the system perl shouldn't start using incompatible versions, as using INSTALL_BASE ought to include both version number and archname -- it doesn't do this on win32 (for some unknown reason), but it should do it on other operating systems

Hello Perl300,

Since you are running *nix, I'll comment on what I do.

Typically, I have at least 3 or 4 Perls on any *nix boxes that I am the admin for. I use the '/usr/local/bin/' to have a symbolic link to the 'non-system' Perl, which I usually install in '/usr/opt/'. Today, I never touch the system Perl and all updates come from the OS update mechanism.

So let's do an example:

• I download Perl ( 5.22.1 ) to '/home/Perl/Perl5.22.1/'.
• I follow the directions for a quick install (usually works perfectly) and configure to install with:
      config_args='-des -Dprefix=/usr/opt/perl5.22.1 -Dusethreads . . .'
• After all makes work, I issue:
      ln -s /usr/opt/perl5.22.1/bin/perl5.22.1   myperl # myperl is unique name for each Perl
      Test: myperl -V

If you want to use 'cpan' on the command line, then do a link to the specific one ( ie, mycpan ). I find it easier to
    myperl -MCPAN -e 'install "..."'

Note 1: I've found problems with Perls that are not owned by root. YMMV.

Note 2: I usually have 2 Perls for each version, 1 with threads and 1 without. On the *nixes I use, threads has a lot of overhead.

Regards...Ed

A method for this that I've used in the past is to have an account other than root for building software (then only run the install step as root). If you have (or can make) such an account, simply chown -R not-root /opt/apps/perl/perl5220, run the CPAN tools as not-root, and see if it works.

Since you are not running the install as root, it will fail if an attempt is made to write to the system perl, and you can be confident that, at worst, only the app perl that you were trying to change can be messed up.

Afterwards, chown -R root /opt/apps/perl/perl5220 will put things back the way they were.

Unless, of course, /opt/app/perl/perl5220 is already owned by an account other than root, in which case you can avoid the chown dance and can simply run the CPAN tools under that account, where they will not be allowed to touch the system perl.

A final caveat: This assumes that the system perl is owned by root. If the system perl is not owned by root, then you will need to figure out who changed that and why.

Somehow it didn't work when I tried /opt/apps/perl/perl5220/bin/perl -MCPAN -e shell and then cpan[1]> install cpanm as mentioned in the documentation of cpanm. Gave "Warning: Cannot install cpanm, don't know what it is." But I am good to go now so updated title of post as resolved.

Thank you for all your inputs.

as mentioned in the documentation of cpanm

Where did you find it? See INSTALLATION.

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

I referred the one at: https://metacpan.org/pod/distribution/Menlo/script/cpanm-menlo

There is another one at:https://metacpan.org/pod/distribution/App-cpanminus/bin/cpanm and I think I should have referred this one. My bad.