This may sound obtuse but why not just build Perl where you want it? Seems likely to be far less problematic to me.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Tachyon,
Thanks for the reply. The problem is that these folk have been using Perl since 4.0 and they put their system together long ago without thinking of the consequences of their actions. Now they have a fairly significant amount of Perl code on about 20 client sites that needs to be kept in synch for maintainance purposes. So they are looking for a way to take advantage of say /usr/local/bin/perl rather than always having to rely on /MyDirectory/soft/perl.

I suppose the simplest thing might be to grep for the #! line at the top of each Perl script and change that line to the build on that particular client system. However that does have the potential to cause problems while they upgrade their code base periodically.

I am still curious to see if there is a way of getting the Perl script to look for other Perl builds on the system and use them instead - I suppose a CPAN module might do this?

I have built Perl a number of times before and then later wanted to move it to another directory (ran out of disk space, whatever...), I have found the most effective way of doing it was to delete Perl and reinstall it. Simply moving it screwed up relationships to modules, man pages etc. Perl must keep the information on the $PERL_BIN, $PERL_LIB, $PERL_MOD somewhere, do you know of any environmental options that might be tinkered with to allow for the Perl directory to be moved somewhere else?
Thanks for your help.

MadraghRua
yet another biologist hacking perl....

This is exactly the kind of problem that make and relatives were invented for.

Just have a development environment with a source tree and a make script that builds a destination tree from that with appropriate information inserted. You then work in a development environment where you edit the source tree, and then build a destination tree and test there. Moving into production you update the source and build the destination. Installing for a client you create a source tree, build the destination, then delete the source.

The extra step may seem like a nuisance, but if the make process is only a simple substitution, then the build time can easily be under a second. And for that second what you get back in flexibility pays for itself again, and again, and again...

As far as I know the answer is no. I you think about @INC you will know you can not change it once Perl is built althought Perl does provide a mechanism to modify it on a script by script basis.

I would just move the scripts and build Perl where you want it. This little script will "re-shebang" them as required. It will retain all the existing -wT type flags. It does all the scripts that end in .pl or .cgi under the $root_dir.

#!/usr/bin/perl -w

use strict;
use File::Find;

my $root_dir = '/temp';
my $new_shebang = '#!/usr/bin/local/perl';

find ( \&fix_shebang, $root_dir );

sub fix_shebang {
    return unless /\.(?:pl|cgi)/;
    local $/;
    open F, "+<$_" or die "Can't open $_: $!\n";
    my $file = <F>;
    if ($file =~ s/^#!.*perl(.*)\n/$new_shebang$1\n/) {
        seek F, 0, 0;
        truncate F, 0;
        print F $file;
        print "Found and modified: $File::Find::name\n";
    }
    else {
        print "Found (no modify):  $File::Find::name\n";
    }
    close F;
}
[download]

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print