How can I control the Perl version used when submitting grid jobs?

Question

I'm working with SGE (Sun Grid Engine) to submit jobs to a grid. I also use perlbrew to manage my installed Perl versions. I wrote some short sh scripts that I use to run a perl script which requires a specific Perl version (5.12.2), which look something like this:

#!/bin/bash
#$-S /bin/bash

source /home/dave/.bash_profile
/home/dave/perl5/perlbrew/bin/perlbrew switch perl-5.12.2

/home/dave/scripts/proc_12.pl --in=/home/dave/in/in.store --dir=/home/dave/in/dir2 --params=/home/dave/in/params.p

Now, when I submit a single job everything works fine, but when I submit many, I start getting perlbrew related error messages, like:

ln: creating symbolic link `current' to `perl-5.12.2': File exists
ln: creating symbolic link `/home/dave/perl5/perlbrew/bin/cpan' to `/home/dave/perl5/perlbrew/perls/current/bin/cpan': File exists
ln: creating symbolic link `/home/dave/perl5/perlbrew/bin/cpan2dist' to `/home/dave/perl5/perlbrew/perls/current/bin/cpan2dist': File exists
ln: cannot remove `/home/dave/perl5/perlbrew/bin/cpanp': No such file or directory
ln: cannot remove `/home/dave/perl5/perlbrew/bin/enc2xs': No such file or directory
ln: cannot remove `/home/dave/perl5/perlbrew/bin/find2perl': No such file or directory

So I guess the /home/dave/perl5/perlbrew/bin/perlbrew switch perl-5.12.2 line is causing the problems.

What can I do?

How can I make my script run using perl-5.12.2 (the default is 5.8.8)?

Answer 1

I don't recommend putting the perlbrew switch perl-5.12.2 in any script you run. Its really only for command line usage.

If you need a script to use a specific version of Perl then either give it the full perlbrew path on the shebang:

#!/home/dave/perl5/perlbrew/perls/perl-5.12.2/bin/perl

use 5.012;
use warnings;
...

Then make sure its executable and run like so:

chmod +x your_perl_program.pl
./your_perl_program.pl

Or alternatively use the full pathname to the perl binary in your script:

#!/bin/bash

/home/dave/perl5/perlbrew/perls/perl-5.12.2/bin/perl your_perl_program.pl

BTW, you will have potential production and security issues if you run anything unqualified in your scripts or perl programs. For eg:

#!/bin/sh

# security risk
perl some_script.pl

# and not just perl
tar cvf archive.tar *.txt

# production risk
/home/dave/perl5/perlbrew/bin/perl some_other_script.pl

The first two are bad because it will pick up the first perl & tar it finds in your path. So this depends on $PATH setting and this could become a security risk. The last is also not good because its reliant on what perl perlbrew is currently switched to at the point in time its run :(

So doing this can be a potential production & security nightmare. Instead the above should be written like this:

#!/bin/sh

# fully qualified now.  Uses OS provided perl
/usr/bin/perl some_script.pl

# ditto
/usr/bin/tar cvf archive.tar *.txt

# this needs to run in perl 5.12.2
/home/dave/perl5/perlbrew/perls/perl-5.12.2/bin/perl some_other_script.pl

Hope that all makes sense?

Answer 2

I'd recommend against using perlbrew. It doesn't really give you that much value and it just causes confusion about what perl you are using. perlbrew really assumes that everything running at the same time agrees on which perl they should use. I think that's just a recipe for headaches as different programs start switching perls out from under you, perhaps before you get the chance even to use the perl you think you switched to.

Just install the perls that you want and call the one that you want.

 $ perl5.12.2 /home/dave/scripts/proc_12.pl ...

For instance, to install a perl you just run from the source tree (with whichever prefix you want):

 $ ./Configure -des -Dprefix=/usr/local/perls/perl-5.12.2
 $ make install

I then make symlinks to all my installed perls with my make_links script. When I want to use Perl 5.12.2, I just use ~/bin/perl5.12.2. I never have to switch perls. When I want to install a Perl module, I use the cpan for it:

 cpan5.12.2 Some::Module

I've never unsure about what version I'm using, and there's no race condition in moving symlinks around.