Different perl locations on different servers.

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

I'm trying to learn the best way to manage having different perl locations on different servers. I like to test my CGI Perl scripts on my own laptop, work computer and actual site, but they all have different locations for perl. Currently, I deal with this by adding the following to the beginning of each perl script.

#! /bin/sh 
if [ `uname -n` = "-- computer name --" ] then 
eval ' exec /sw/perl/5.6.1/WS/7/bin/perl -x $0 "$@" ' 
else 
eval ' exec /usr/bin/perl -x $0 "$@" ' fi 
#! perl
[download]

Is there a better way to deal with this? Perhaps within perl rather than relying on /bin/sh ?

TIA
Jake

Comment on Different perl locations on different servers. Download Code

Replies are listed 'Best First'.
Re: Different perl locations on different servers. by Fletch (Bishop) on Nov 02, 2007 at 13:56 UTC
You could use `env` to do it (which will search `PATH`, so have that set correctly) like `#!/usr/bin/env perl`. Or another possibility would be to try and find somewhere (maybe `/home/mylogin/bin/perl`) which you can keep constant across all your platforms and then make that symlink to the correct local version. We're looking for a Perl and Database Developer for Corporate Investments Group.	[reply] [d/l]
Re^2: Different perl locations on different servers. by JakeIII (Novice) on Nov 27, 2007 at 13:08 UTC
Thanks. Unfortunately, env is not available on all of the systems. Plus, there's no guarantee that it'd get the desired version. Jake	[reply]
Re: Different perl locations on different servers. by KurtSchwind (Chaplain) on Nov 02, 2007 at 14:27 UTC
The env approach isn't bad. You'll find this to be kind of an ongoing issue though. It may be overkill, but you might look into auto-confiscating your code. In the end you could deploy your code with something akin to: `./configure --with-perl=/sw/perl/5.6.1/WS/7/bin/perl make make install` [download] This would automatically re-write (substitute) the path string in the files you wanted to. It's an extra layer, but it's precisely why autoconfiscation was invented. To handle the niggling differences between systems. Autoconfiscating works pretty well across platforms. If you'd need a template for setting it up, let me know. It's a lot easier than it looks initially. (Kind of like perl itself). -- I used to drive a Heisenbergmobile, but everyone I looked at the speedometer, I got lost.	[reply] [d/l]
Re^2: Different perl locations on different servers. by JakeIII (Novice) on Nov 27, 2007 at 13:12 UTC
Thanks. My code is rarely complex enough to require the configure/make approach. Also, I only have ftp access to one of the servers so I couldn't actually run it. Well, I could, but I'd have to write it in a CGI script and then "run" that web page. Jake	[reply]
Re: Different perl locations on different servers. by tuxz0r (Pilgrim) on Nov 02, 2007 at 16:40 UTC
You can also use a small script to set the `perl` path explicitly in the files before running on each environment. At least, for testing purposes - I would recommend keeping the production path in the files that are in version control. For example, here's a quick version that would replace the `#!/path/to/perl` line at the top of each file with a path that you pass in: #!/bin/sh PERL=$1 for file in `find . -name '.pl'` do perl -i -ape 's/^#!\s(.perl)\s(.*)$/#!$ENV{PERL} $2/;' $file done [download] I have a script similar to this that I use to increment the release version in all the '`configure.in`' files in our release packages at work, so I think this might help you out. --- echo S 1 [ Y V U \| perl -ane 'print reverse map { $_ = chr(ord($_)-1) } @F;'	[reply] [d/l]