The canonical approach would be to use

Differing paths to env will torpedo this, of course.

Use symlinks.

Example: Desired perl on AIX is /usr/my/shiny/AIX-Perl/bin/perl, desired perl on Linux is /opt/my-shiny-perl5/bin/perl. Create a symlink /usr/local/bin/my-shiny-perl on both systems, pointing to the former on AIX, to the latter on Linux. Change the shebang line to #!/usr/local/bin/my-shiny-perl.

Alexander

Thank you for your post. The situation actually is like this. I have AIX clients and Linux clients. They are running a perl script that resides on a server . However instead of using the local Perl interpreter they are using the Perl on the server with NFS. Now the script on the server should check which OS the client has ( by checking $^O from within the script) and then decide which Perl path to choose . How do I deal with shebang line in this case?

Use symlinks on the clients. Change the shebang line to the fixed location of the symlink (#!/usr/local/bin/my-shiny-perl in my example). Make the symlink point to the perl interpreter you want to use. It does not matter where the interpreter is installed (locally or on the NFS server).

$^O happens when perl is already running, so that's too late. You choose perl by the local symlink.

Of course, you can have some kind of installer script that actually creates the local symlink. Something like this (untested):

#!/usr/bin/env perl
# ^-- use any perl available
use strict;
use warnings;

my $shinyperl=($^O eq 'linux') ? '/nfs/linux/bin/perl' : '/nfs/aix/bin
+/perl';
symlink($shinyperl,'/usr/local/bin/my-shiny-perl') or die "Create syml
+ink failed: $!";
[download]

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Another option, if you want to avoid local symlinks at all costs, is to use the default shell and make that decide which perl to run, using the uname command:

#!/bin/sh
if [ "$(uname)" = "Linux" ] ; then
    perl="/nfs/linux/bin/perl"
else
    perl="/nfs/aix/bin/perl"
fi
exec "$perl" /nfs/commom/perl/the-script.pl "$@"
[download]

You can merge this loader script and the perl code into a single script, see perlrun. This will look something like this:

#!/bin/sh
if [ "$(uname)" = "Linux" ] ; then
    perl="/nfs/linux/bin/perl"
else
    perl="/nfs/aix/bin/perl"
fi
exec "$perl" -x $0 "$@"
#!perl
# ^- "perl -x" searches for this line. Linux and AIX don't care about 
+this line.
use strict;
use warnings;
print "Hello World!\n";
[download]

I don't know much about AIX. You may need to replace "$@" with ${1+"$@"}, see perlrun and http://www.in-ulm.de/~mascheck/various/bourne_args/. Also, uname and even test ([] may behave different than on linux.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Thank you for your post. The situation actually is like this. I have AIX clients and Linux clients. They are running a perl script that resides on a server . However instead of using the local Perl interpreter they are using the Perl on the server with NFS. Now the script on the server should check which OS the client has ( by checking $^O from within the script) and then decide which Perl path to choose . How do I deal with shebang line in this case?

perl ./my_script.pl arg1 arg2
[download]

Welcome dumb_fellow,

I have the same situation with AIX and Linux servers. I have found that the easiest method for me is to have the common shebang to be:

     #!/usr/local/bin/pyrperl
[download]

I never type 'perl', but always 'pyrperl', so on all machines I'm working with a known and tested Perl. YMMV.

Regards...Ed

Maybe check Can I write a transparent shell wrapper to start the correct build of Perl? for a similar question. Maybe one of the answers there will help?