Re^2: Installing a Second perl

[JavaFan]

Running as user, you can't install to usr/local as you don't have permissions. The 'make install' phase needs to be run as root.

Not true. On almost all boxes I run, I install my own perl. Most of them don't need root access at all - except for the creation of a single directory. Here's a way the OP could do it:

$ sudo mkdir /lab/perl
$ sudo chown your_user_name: /lab/perl
$ ... Fetch tarball ...
$ ... Unpack tarball ...
$ ... cd source directory ...
$ ./Configure -des -Dprefix=/lab/perl
$ make && make test && make install
$ /lab/perl/bin/perl -MCPAN -eshell   # Configure CPAN
$ /lab/perl/bin/cpan -i Module1 Module2 Module3 Module4 ....

No need to run any code downloaded from the internet as root. I typically create a dedicated "perladmin" user to manage the boxes perl and CPAN modules. /opt/perl is my favourite directory to install it in - with /usr/bin/perl a symlink to /opt/perl/bin/perl. (Making the symlink requires root access as well). If you're too scared to get rid to the "system perl"¹, move /usr/bin/perl to /usr/bin/systemperl, and change the shebang line of any script that needs the "system perl" and fails on your own perl accordingly.

1	After all, technology we don't understand is cannot be distinguished from magic.

[Corion]

IMO it's less a matter of understanding and more a matter of separation of concerns. The system Perl is administered, configured (and tested, hopefully) by the OS vendor while the "other" Perl is administered and configured by you. You will soon enough have requirements (like threads for example) that differ from the requirements that the OS vendor has (speed for short running scripts) and that the OS vendor does not test for. Trying to bridge that gap without close integration with the OS vendor is a big endeavor if you're not dedicated to administrating a system.