What if you go the other way? At the top of your perl scripts put this:

#!/bin/sh

eval '. /etc/host.conf; exec /nfs/perl/5.10/${HOST_PLATFORM}/bin/perl 
+-S $0 ${1+"$@"}'
    if 0;
[download]

Thanks, yes, that's plan B. If there have to be crude shell gubbins going on I would ideally wish that they were invisible to the Perl programmer, if you know what I mean.

Not sure I entirely understand your specific requirements, but why not create a symlink in the local filesystem (I'm assuming there is a local filesystem...) which points to the respective NFS location, e.g.

ln -s /nfs/perl/5.10/centos5/bin/perl /usr/local/bin/perl
[download]

for a centos5 machine. This is a one-time administration thing, and your shebang line in the Perl script would then simply be #!/usr/local/bin/perl.

Symlinks don't work on the shebang line, IME.

Why not, what's the problem? I've been using them like this for ages without any issues I could remember.  Resolution of symlinks is a rather low-level kernel feature, which should be handled transparently by any modern version of Unix.

PS: anyone interested in how it's done in Linux may want to study the function load_script in linux/fs/binfmt_script.c, which calls open_exec (linux/fs/exec.c), which in turn eventually branches (via path_lookup_open) into the generic path lookup and symlink resolution code implemented in linux/fs/namei.c.

There's a potential subtle problem with using env, which is that you typically can't pass arguments to the perl binary this way, like for example

#!/usr/bin/env perl -w
[download]

On my Debian Linux this produces

$ ./666330.pl
/usr/bin/env: perl -w: No such file or directory
[download]

This is not a problem with env (running /usr/bin/env perl -w 666330.pl from the command line would work fine...), but rather with many Unix kernels, which treat everything after the interpreter specified on the shebang line (here /usr/bin/env) as a single argument, i.e. it would pass "perl -w" to /usr/bin/env as the program name to execute... which of course doesn't exist. This can easily be seen with strace:

$ strace -e trace=execve ./666330.pl
execve("./666330.pl", ["./666330.pl"], [/* 24 vars */]) = 0
execve("/home/almut/bin/perl -w", ["perl -w", "./666330.pl"], [/* 24 v
+ars */]) = -1 ENOENT (No such file or directory)
execve("/usr/local/bin/perl -w", ["perl -w", "./666330.pl"], [/* 24 va
+rs */]) = -1 ENOENT (No such file or directory)
execve("/usr/bin/perl -w", ["perl -w", "./666330.pl"], [/* 24 vars */]
+) = -1 ENOENT (No such file or directory)
execve("/bin/perl -w", ["perl -w", "./666330.pl"], [/* 24 vars */]) = 
+-1 ENOENT (No such file or directory)
execve("/usr/bin/X11/perl -w", ["perl -w", "./666330.pl"], [/* 24 vars
+ */]) = -1 ENOENT (No such file or directory)
/usr/bin/env: perl -w: No such file or directory
[download]

I fixed builds that attempted to use the -w option when calling perl. The shell was treating it as a single command name rather than a command with a switch. The easy way to fix this would be to do something similar to: ln -s ./perl 'perl -w' This will create a symbolic link named 'perl -w' allowing the build to work, in my case. I was running into this with trying to compile the library pango and it was annoying me, because I couldn't figure out where env was calling for the file 'perl -w' to change it. The -w switch only enables some additional warnings, so not entirely necessary. Another option might be to create a script named 'perl -w' then have it call perl with the -w switch.

The second thing that comes to mind is how does this script behave if /etc/host.conf is empty.

It's not. If it is, the machine has bigger problems than perl not working.

Shouldn't you define HOST_PLATFORM with some kind of sane default value before you source /etc/host.conf?

There is no sane default value.

Could the script figure it out for itself, with 'uname -a' perhaps?

Not trivially. But it doesn't matter, as the host.conf file is reliable.

Another issue is that using variables in all capital letters in a shell script guarantees name collisions with the OS environment variables.

That's not the actual variable name. None of the paths or filenames I gave are real. Our platforms aren't really called centos4 and centos5. The main reason for this is that the real values all contain the company name, and I'd rather not get fired ;)

#!/bin/sh

. /etc/host.conf

exec /nfs/perl/5.10/$HOST_PLATFORM/bin/perl "$@"
[download]

I know this is an old thread, and I know I've already responded to it, but, since then, I've come up with and am using a completely different method for dealing with situations similar to this.

I have a "dev_perl" script. Written in perl. And I put that into the #! line. (Well, I actually have it in the PATH and use #!/bin/env dev_perl, but close enough.)

So, this dev_perl script is something like this:

#!/usr/bin/perl

my $os = $^O; # You may need something more complex - I do
my $version = '5.10'; # I need more complex than this

exec "/nfs/perl/$version/$os/bin/perl", @ARGV;
[download]

Note how this script uses /usr/bin/perl - which should exist on all unix-like platforms. And the main reason for all this extra overhead? Because doing the complex stuff is far easier in perl than shell.

Thanks a ton for this post! I applied the same technique and was successful!. It made my day. :-)