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.
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.
Bill
Stas Bekman wrote:
Geoffrey Young wrote:
William A. Rowe, Jr. wrote:
Both lib/Apache/TestConfig.pm and lib/Apache/TestUtil.pm twist off their
own shebang lines from $Config{perlpath}, which is wrong.
I think part of this stems from this
http://www.gossamer-threads.com/lists/modperl/dev/86017
Mike's patch used the original $Config{perlpath}, so no change there.
They should simply pull $Config{startperl} which defines the
shebang/command
on a platform basis. See startperl= assignment from Config.pm.
You mean using $Config{startperl} instead of the hardcoded
#!/usr/bin/perl when the path is too long? I think that value makes no
difference. At least not according to these resources:
# see: http://en.wikipedia.org/wiki/Shebang
# http://homepages.cwi.nl/~aeb/std/shebang/
If you have better ideas that would be wonderful :)
