Both lib/Apache/TestConfig.pm and lib/Apache/TestUtil.pm twist off their
own shebang lines from $Config{perlpath}, which is wrong.
They should simply pull $Config{startperl} which defines the shebang/command
on a platform basis. See startperl= assignment from Config.pm.
Please ack / discuss / commit?
Thanks,
Bill
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
>
> They should simply pull $Config{startperl} which defines the
> shebang/command
> on a platform basis. See startperl= assignment from Config.pm.
which looks ok, but the perlpath foo in TestConfig.pm and TestRun.pm has
been there for ages I think. are you sure that startperl goes back to 5.00503?
that said, we also use startperl in TestConfig, which is also the result of
discussions near the above thread. hmm...
>
> Please ack / discuss / commit?
ack and discuss :) let's hold off on making any changes until we are really
sure we won't be breaking old platforms. speaking of breakage, which
platform is giving your grief with this? randy reported success with win32
so it's something else?
--Geoff
Geoffrey Young wrote:
>
> ack and discuss :) let's hold off on making any changes until we are really
> sure we won't be breaking old platforms. speaking of breakage, which
> platform is giving your grief with this? randy reported success with win32
> so it's something else?
Something else. My perl/bin/perl script fixes up the libpath info to openssl,
the current install location of perl, etc. So without the $Config{startperl}
location to invoke perl-as-shell (I had a horrid time with shebang syntax on
non-bash older /bin/sh shells using perlscript) - I'll continue to have
difficulty testing parallel installs.
Your point to perl versions is good; the make_shebang is a hack around something
that can be trivially hacked into the base perl instead (in Config.pm). Since
perl 'figures this out', my preference is for perl to get it right (or wrong,
and therefore fixed once per platform/deployment strategy.)
So the question; how far back? I just went to a box with an honest to goodness
5.005.03 sun4-solaris distribution of perl and lo and behold,
startperl='#!/usr/bin/perl' is there.
Which brings up another aspect of tweaking startperl, that is, when meaning to
test several parallel flavors of perl. But coming back on point, yes I quite
believe this will work across the board.
Bill
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 :)
--
____________________________________________________________ _
Stas Bekman mailto:stas@stason.org 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/
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 :)
>
>
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"
: <
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:stas@stason.org 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/
>> 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?
not to be dense, but I'm not really following either.
ordinarily, I'd say "fine, you get it, so go ahead and fix it" except that I
think it's important to understand exactly why perlpath doesn't work because
of this in TestRun.pm
$^X = $Config{perlpath} unless -e $^X;
so if we change to startperl across the board then we're still manipulating
the shebang - instead of adding it like we do now we'll be stripping it
here. the current situation has the advantage of being time tested, which
is why I'm hesitant to change it blindly and without a real understanding of
why startperl over pathperl mysteriously solves "the problem"
but thanks for putting up with me :)
--Geoff
Stas Bekman wrote:
> 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"
> : <
> eval 'exec $Config{perlpath} -S \$0 \${1+"\$@"}'
> if \$running_under_some_shell;
> EOI
>
> return $shebang;
> }
>
> Should probably be: $Config{sh}
Good point ;-)
>> 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?
$Config{sh}, $Config{perlpath}, and $Config{perl} comes from -this- perl, right?
#/usr/bin/perl is a hardcode to an arbitrary perl installed at that location.
What I'm trying (failing?) to point out is that on BSD and other platforms, if
they have a bug, they can munge *PERL*, not ApacheTest, not each and every perl
script which creates perl files, with an effective value of $Config{startperl}.
I don't have a BSD box in front of me; but if ApacheTest used $Config{startperl}
rather than all of this other mechanics, then it would be up to BSD folks
to help the entire Perl community by fixing this ONCE with MakeMaker, and be
done with it. By messing with constructing what MakeMaker's done since 5.0005
we are putting more work on ourselves, no?
> Bill, mind to post a patch of what you think should work?
Yes, revert this patch, and replace these lines with = $Config{startperl}.
When I have a clean patch against head I'll post it. I'll also look at the
state of MakeMaker to see if this issue -was- addressed there.
Bill
William A. Rowe, Jr. wrote:
[...]
> $Config{sh}, $Config{perlpath}, and $Config{perl} comes from -this-
> perl, right?
right
> #/usr/bin/perl is a hardcode to an arbitrary perl installed at that
> location.
>
> What I'm trying (failing?) to point out is that on BSD and other
> platforms, if
> they have a bug, they can munge *PERL*, not ApacheTest, not each and
> every perl
> script which creates perl files, with an effective value of
> $Config{startperl}.
What you are missing Bill, is that there is no bug in perl or perl
installation. It's a shell limitation documented here:
# see: http://en.wikipedia.org/wiki/Shebang
# http://homepages.cwi.nl/~aeb/std/shebang/
Hence the workaround was added.
> I don't have a BSD box in front of me; but if ApacheTest used
> $Config{startperl}
> rather than all of this other mechanics, then it would be up to BSD folks
> to help the entire Perl community by fixing this ONCE with MakeMaker,
> and be
> done with it. By messing with constructing what MakeMaker's done since
> 5.0005
> we are putting more work on ourselves, no?
I think there are two somewhat unrelated issues that are being discussed
here -
1) using $Config{startperl} vs $Config{perlpath},
2) the issue with shebang code generation
I think Geoff is thinking that Bill is suggesting to tackle #1, whereas
Bill is only talking about #2.
>> Bill, mind to post a patch of what you think should work?
>
> Yes, revert this patch, and replace these lines with = $Config{startperl}.
> When I have a clean patch against head I'll post it. I'll also look at the
> state of MakeMaker to see if this issue -was- addressed there.
--
____________________________________________________________ _
Stas Bekman mailto:stas@stason.org 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/
Stas Bekman wrote:
> William A. Rowe, Jr. wrote:
>
>> What I'm trying (failing?) to point out is that on BSD and other platforms, if
>> they have a bug, they can munge *PERL*, not ApacheTest, not each and every perl
>> script which creates perl files, with an effective value of $Config{startperl}.
>
> What you are missing Bill, is that there is no bug in perl or perl
> installation. It's a shell limitation documented here:
>
> # see: http://en.wikipedia.org/wiki/Shebang
> # http://homepages.cwi.nl/~aeb/std/shebang/
Right - I'm not disagreeing with the problem, I'm stating $Config{startperl}
when used by every program against your perl is either right, or it's wrong.
When Wrong, it's wrong for every program. Ergo; bug is MakeMaker's to fix,
not ours, and...
>> I don't have a BSD box in front of me; but if ApacheTest used
>> $Config{startperl}
>> rather than all of this other mechanics, then it would be up to BSD folks
>> to help the entire Perl community by fixing this ONCE with MakeMaker,
>> and be
>> done with it. By messing with constructing what MakeMaker's done
>> since 5.0005
>> we are putting more work on ourselves, no?
>
> I think there are two somewhat unrelated issues that are being discussed
> here -
>
> 1) using $Config{startperl} vs $Config{perlpath},
>
> 2) the issue with shebang code generation
....startperl is declared with a shebang, perl -e "print $Config{startperl};"
in your own environment :) So the two are -one-in-the-same-
> I think Geoff is thinking that Bill is suggesting to tackle #1, whereas
> Bill is only talking about #2.
I'm stating use startperl; both of you want the shebang bug (not ours) fixed,
so as I...
>>> Bill, mind to post a patch of what you think should work?
>>
>> Yes, revert this patch, and replace these lines with = $Config{startperl}.
>> When I have a clean patch against head I'll post it. I'll also look at the
>> state of MakeMaker to see if this issue -was- addressed there.
....propose to throw away the gross hack, it's only fair if I show you also the
perl patch to create a *valid* MakeMaker $Config{startperl} result for those
on these shebang-constrained platforms. Let's fix the bug, not a symptom.
Bill