perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: Syntax issue in Apache/
Date Thu, 23 Feb 2006 09:46:53 GMT
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:
     my $shebang = length $Config{perlpath} < 62
         ? "#!$Config{perlpath}\n"
         : <<EOI;
     eval 'exec $Config{perlpath} -S \$0 \${1+"\$@"}'
         if \$running_under_some_shell;

     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
MailChannels: Assured Messaging(TM)
The "Practical mod_perl" book

View raw message