It actually *does* work beautifully if you call perl from the commandline. In that case, you're just calling the shell script, which exec's to the appropriate perl binary.
It's the case of the hundred of perl scripts/tools which invoke the perl interpreter in the top line. The unix kernel performs magic to figure out how to handle the file you name there, or whether that file is a shell script, and then which shell interpreter to call.
And it does seem to work if I call the perl script/tool as you say:
<perlpath>/bin/perl myperlscript.pl
This seems to work. Actually, if the tool is called through a wrapper, and that tool wrapper calls the tool as above, that will work! I think this is the solution!!
## my tool:
perl-script-to-do-some-work.pl -> .multi-perl588-wrapper
## the wrapper finds the latest released version of the
## tool, and does an exec:
PERL=<perlpath>/bin/perl
EXE=<tool-root>/<tool-version>/bin/<tool>
exec $PERL $EXE "$@"
## that $PERL does exec, if on i386:
exec <perlpath>/i386/bin/perl
## if on sparc
exec <perlpath>/sparc/bin/perl
The key to this is to make sure the tool is wrapped, so that the wrapper can get both the tool release version, and also call it using an explicit perl override.
Hey, that was the ticket!! All our tools are wrapped anyway, so this will work perfectly!!!
Monks rock!
| [reply] |
As a matter of fact, I have the same shell problem - not related to perl - and this thread was basically the only place where I could find some useful info.
--- cut here ---
I solved by modifying my shebang line to:
#!/usr/bin/env /path/to/my/wrapper
#
# and the script follows...
--- cut here ---
Thank you all
| [reply] |