William A. Rowe, Jr. wrote:
I don't think the reporter understood the concept of
#!/usr/bin/perl
eval 'exec $Config{perlpath} -S \$0 \${1+"\$@"}'
if \$running_under_some_shell;
which is a noop under perl, and invokes a shell exec command under
shell. Perl
never invokes the exec ($running_under_some_shell is undef and therefore
noop).
In this case, /usr/bin/perl is running their script, even if perlpath
pointed
to /usr/local/perl5.8/bin/perl - and that's the last possible scenario
we want.
If the reporter wanted this hack to work, #!/bin/sh was the proper line
one.
You mean:
sub make_shebang {
# if perlpath is longer than 62 chars, some shells on certain
# platforms won't be able to run the shebang line, so when seeing
# a long perlpath use the eval workaround.
# see: http://en.wikipedia.org/wiki/Shebang
# http://homepages.cwi.nl/~aeb/std/shebang/
my $shebang = length $Config{perlpath} < 62
? "#!$Config{perlpath}\n"
: <<EOI;
#bin/sh
eval 'exec $Config{perlpath} -S \$0 \${1+"\$@"}'
if \$running_under_some_shell;
EOI
return $shebang;
}
Should probably be: $Config{sh}
In any case, this sort of hack should be left to the value of
$Config{startperl}
where it belongs, not a dozen workarounds in a dozen different projects.
I'm not following you, how $Config{startperl} solves the problem of the
long path, if just as you say it makes the script run under the wrong perl?
Bill, mind to post a patch of what you think should work?
--
_____________________________________________________________
Stas Bekman mailto:[EMAIL PROTECTED] http://stason.org/
MailChannels: Assured Messaging(TM) http://mailchannels.com/
The "Practical mod_perl" book http://modperlbook.org/
http://perl.apache.org/ http://perl.org/ http://logilune.com/
