Nice. I feel silly for how many scripts I’ve edited around this problem when there was such a simple and obvious way around it. Next time I need to update something, I’ll try this approach.

#!/bin/sh
perl -I /some/special/libpath:/another/special/libpath "$@"
[download]

Drop in an exec to get rid of a needless /bin/sh instance:

#!/bin/sh
exec perl -I /some/special/libpath:/another/special/libpath "$@"
[download]

And if you have more than one perl, specify which one you want to start. Also do this if you are not sure what $ENV{'PATH'} may contain.

#!/bin/sh
exec /usr/local/perl-5.42.99/bin/perl -I /some/special/libpath:/anothe
+r/special/libpath "$@"
[download]

But then again, cbeckley++ is right, perl can do fine without a shell:

#!/usr/local/perl-5.42.99/bin/perl 
use lib '/some/special/libpath','/another/special/libpath';

# rest of the script here, unmodified
[download]

Perl does not even mind if you prefix those two lines to an existing script, the shebang (#!) line of the existing script will be parsed as a comment.

If you don't want to modify scripts, you can also use a perl script as a wrapper:

#!/usr/local/perl-5.42.99/bin/perl 
use lib '/some/special/libpath','/another/special/libpath';
require '/path/to/real/script.pl';
[download]

(untested)

This simple one assumes that script.pl returns a true value. Alternatively, use do $filename, but that needs more code for error handling:

#!/usr/local/perl-5.42.99/bin/perl 
use lib '/some/special/libpath','/another/special/libpath';
unless (defined(do '/path/to/real/script.pl')) {
    die "Could not parse script: $@" if $@;
    die "Could not read script: $!";
}
[download]

(untested)

Generally, if you run a script as root or setuid root, consider adding -T to the shebang line to enable taint mode (see perlsec).

Alexander

I've tried your suggestion and the one provided by cbeckley.

Both work, but are there reasons for choosing one approach over the other?

Thanks -F

In the "-I" approach the biggest consideration comes from module movement. If the modules move from /some/location to /another/location only one place (/usr/bin/perlcron) needs to change and all the programs using those modules are repaired. When using findbin/lib each program itself has to be repaired. At one site i was at we moved boxes 4 times in about 7 years, each move with changes to the names of the file system paths. In that case it wasnt for cron, but to ensure a working production environment. As soon as i fixed the initiator-script all the processes worked under the new locations. I also use this method still on my home boxes, various windoz and linuxen, each with its own customized initiator script to let it run in that environment.

I would only add that if the scripts and the modules are going to maintain their relative positions in the file system before and after a move, then no change is required with

use lib "$FindBin::Bin/../path/to/modules";
[download]

However if there's a risk that the modules might move in relation to the scripts, then huck's solution is certainly more flexible.

Thanks,
cbeckley