git-instaweb portability issue (maybe?)

> That line simply calls perl by the $PERL variable, which is set at the
> top of the script, like so:
>
>    PERL='/usr/bin/env perl'
>
> If I change this line to point to my perl directly, it works.  On a
> hunch, I changed it to:
>
>    PERL="/usr/bin/env perl"  # note the double-quotes

> On Fri, Jun 13, 2008 at 09:26, Denis Bueno <dbueno@gmail.com> wrote:
>> That line simply calls perl by the $PERL variable, which is set at the
>> top of the script, like so:
>>
>>    PERL='/usr/bin/env perl'
>>
>> If I change this line to point to my perl directly, it works.  On a
>> hunch, I changed it to:
>>
>>    PERL="/usr/bin/env perl"  # note the double-quotes
>
> [snip lies]
>
> Apparently I didn't test this thoroughly enough, and I was wrong.
> Changing the quotes has no effect.
>
> So git-instaweb only works for me if I manually specify my perl path.
> Can anyone think of why this might be?

> On Fri, Jun 13, 2008 at 09:46, Asheesh Laroia <asheesh@asheesh.org> wrote:
>> Does OS X ship /usr/bin/env?
>>
>> If you type "/usr/bin/env perl" in a Terminal window, do you get Perl?
> 
> Sorry, I should have made that clear earlier: yes.
> 
> funsat[122] > /usr/bin/env perl --version
> 
> This is perl, v5.8.8 built for darwin-2level

> Denis Bueno wrote:
>> On Fri, Jun 13, 2008 at 09:46, Asheesh Laroia <asheesh@asheesh.org> wrote:
>>> Does OS X ship /usr/bin/env?
>>> 
>>> If you type "/usr/bin/env perl" in a Terminal window, do you get Perl?
>> 
>> Sorry, I should have made that clear earlier: yes.
>> 
>> funsat[122] > /usr/bin/env perl --version
>> 
>> This is perl, v5.8.8 built for darwin-2level
>
> MacPorts /tends/ to make ports use stuff from other ports instead of using 
> Apple-installed bits. In this case, maybe git from MacPorts is using perl 
> from MacPorts?

> On Fri, 13 Jun 2008, Chris Ridd wrote:
> 
>> Denis Bueno wrote:
>>> On Fri, Jun 13, 2008 at 09:46, Asheesh Laroia <asheesh@asheesh.org> 
>>> wrote:
>>>> Does OS X ship /usr/bin/env?
>>>>
>>>> If you type "/usr/bin/env perl" in a Terminal window, do you get Perl?
>>>
>>> Sorry, I should have made that clear earlier: yes.
>>>
>>> funsat[122] > /usr/bin/env perl --version
>>>
>>> This is perl, v5.8.8 built for darwin-2level
>>
>> MacPorts /tends/ to make ports use stuff from other ports instead of 
>> using Apple-installed bits. In this case, maybe git from MacPorts is 
>> using perl from MacPorts?
> 
> FWIW, the problem seems to be that it's not finding *any* Perl.

> Asheesh Laroia wrote:
>>
>> On Fri, 13 Jun 2008, Chris Ridd wrote:
>>
>>> Denis Bueno wrote:
>>>>
>>>> On Fri, Jun 13, 2008 at 09:46, Asheesh Laroia <asheesh@asheesh.org>
>>>> wrote:
>>>>>
>>>>> Does OS X ship /usr/bin/env?
>>>>>
>>>>> If you type "/usr/bin/env perl" in a Terminal window, do you get Perl?
>>>>
>>>> Sorry, I should have made that clear earlier: yes.
>>>>
>>>> funsat[122] > /usr/bin/env perl --version
>>>>
>>>> This is perl, v5.8.8 built for darwin-2level
>>>
>>> MacPorts /tends/ to make ports use stuff from other ports instead of
>>> using Apple-installed bits. In this case, maybe git from MacPorts is using
>>> perl from MacPorts?
>>
>> FWIW, the problem seems to be that it's not finding *any* Perl.
>
> That's odd, because the Portfile for git-core (1.5.5.3_0) does the build,
> test and destroot install setting:
>
> PERL_PATH="/usr/bin/env perl" NO_FINK=1 NO_DARWIN_PORTS=1
>
> (and some other stuff). Have you pinged the port maintainer
> (bryan@larsen.st)?

> On Fri, Jun 13, 2008 at 09:26, Denis Bueno <dbueno@gmail.com> wrote:
> > That line simply calls perl by the $PERL variable, which is set at the
> > top of the script, like so:
> >
> >    PERL='/usr/bin/env perl'
> >
> > If I change this line to point to my perl directly, it works.  On a
> > hunch, I changed it to:
> >
> >    PERL="/usr/bin/env perl"  # note the double-quotes
> 
> [snip lies]
> 
> Apparently I didn't test this thoroughly enough, and I was wrong.
> Changing the quotes has no effect.

> Try changing the following line instead:
>        "$PERL" -p -e "$script" "$1.tmp"  > "$1"
> to
>        $PERL -p -e "$script" "$1.tmp"  > "$1"
>
> about line 6121 of the git-instaweb script.

> On Fri, Jun 13, 2008 at 10:21, Luciano Rocha <luciano@eurotux.com> wrote:
> > Try changing the following line instead:
> >        "$PERL" -p -e "$script" "$1.tmp"  > "$1"
> > to
> >        $PERL -p -e "$script" "$1.tmp"  > "$1"
> >
> > about line 6121 of the git-instaweb script.
> 
> This is line 6033 for me; however, this change makes it work!  (I
> verified my changing this line; trying it; then changing it back to
> the double-quotes version, and verifying it breaks.)
> 
> Why?

> On Fri, Jun 13, 2008 at 10:39:11AM -0400, Denis Bueno wrote:
>> On Fri, Jun 13, 2008 at 10:21, Luciano Rocha <luciano@eurotux.com> wrote:
>>>
>>> Try changing the following line instead:
>>>        "$PERL" -p -e "$script" "$1.tmp" > "$1"
>>> to
>>>        $PERL -p -e "$script" "$1.tmp" > "$1"
>>>
>>> about line 6121 of the git-instaweb script.
>> 
>> This is line 6033 for me; however, this change makes it work!  (I
>> verified my changing this line; trying it; then changing it back to
>> the double-quotes version, and verifying it breaks.)
>> 
>> Why?
> 
> "$PERL" means the content of the variable is used as the command to
> execute.
> 
> $PERL, on the other hand, goes through a round of word splitting, that
> in your case results in the command "/usr/bin/env", with the arguments
> "perl", "-p", ...
> 
> Thus, if it is possible to use /usr/bin/env, the current "$PERL"
> incantation is incorrect.

> Luciano Rocha <luciano@eurotux.com> writes:
> > On Fri, Jun 13, 2008 at 10:39:11AM -0400, Denis Bueno wrote:
> >> On Fri, Jun 13, 2008 at 10:21, Luciano Rocha <luciano@eurotux.com> wrote:
> >>>
> >>> Try changing the following line instead:
> >>>        "$PERL" -p -e "$script" "$1.tmp" > "$1"
> >>> to
> >>>        $PERL -p -e "$script" "$1.tmp" > "$1"
> >>>
> >>> about line 6121 of the git-instaweb script.
> >> 
> >> This is line 6033 for me; however, this change makes it work!  (I
> >> verified my changing this line; trying it; then changing it back to
> >> the double-quotes version, and verifying it breaks.)
> >> 
> >> Why?
> > 
> > "$PERL" means the content of the variable is used as the command to
> > execute.
> > 
> > $PERL, on the other hand, goes through a round of word splitting, that
> > in your case results in the command "/usr/bin/env", with the arguments
> > "perl", "-p", ...
> > 
> > Thus, if it is possible to use /usr/bin/env, the current "$PERL"
> > incantation is incorrect.
> 
> The problem is with trying to ensure that both
> 
>    /path/with spaces/perl
> 
> and
> 
>    /usr/bin/env perl
> 
> work, as they require different rules wrt. splitting on whitespace...

> I'm on OS X 10.4.11 on Intel using git 1.5.5.3.
> 
> I'd been trying to use the git-instaweb script (both with and without
> arguments) with lighttpd (which I installed through Macports) without
> success, seeing the following kind of bizarre error message:
> 
>     funsat[290] > git instaweb
>     /opt/local/bin/git-instaweb: line 6033: /usr/bin/env perl: No such
> file or directory
>     2008-06-13 09:09:31: (log.c.75) server started
> 
>     funsat[291] > 2008-06-13 09:09:31: (mod_cgi.c.998) CGI failed:
> Exec format error /Volumes/work/funsat/.git/gitweb/gitweb.cgi
>     mod_cgi.c.1001: aborted
>     2008-06-13 09:09:31: (mod_cgi.c.584) cgi died, pid: 23237
> 
> "/usr/bin/env perl: No such file or directory"? Huh?  I certainly have
> perl installed, so I don't know what that's about.
> 
> That line simply calls perl by the $PERL variable, which is set at the
> top of the script, like so:
> 
>     PERL='/usr/bin/env perl'