git-instaweb portability issue (maybe?)

Hi,

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'

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

And now it works.  Could this be changed for future releases of git?
Does this in fact increase portability, or is something more sinister
going on?

Thanks.

-- 
 Denis

On Fri, Jun 13, 2008 at 09:26, Denis Bueno [off-list ref] 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?

-- 
 Denis

On Fri, 13 Jun 2008, Denis Bueno wrote:

On Fri, Jun 13, 2008 at 09:26, Denis Bueno [off-list ref] wrote:

quoted

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?

Does OS X ship /usr/bin/env?

If you type "/usr/bin/env perl" in a Terminal window, do you get Perl?

-- Asheesh.

-- 
Hark ye, Clinker, you are a most notorious offender.  You stand convicted of
sickness, hunger, wretchedness, and want.
 		-- Tobias Smollet

On Fri, Jun 13, 2008 at 09:46, Asheesh Laroia [off-list ref] 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

Denis Bueno wrote:

On Fri, Jun 13, 2008 at 09:46, Asheesh Laroia [off-list ref] wrote:

quoted

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?

Cheers,

Chris

On Fri, 13 Jun 2008, Chris Ridd wrote:

Denis Bueno wrote:

quoted

On Fri, Jun 13, 2008 at 09:46, Asheesh Laroia [off-list ref] wrote:

quoted

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.

-- 
A can of ASPARAGUS, 73 pigeons, some LIVE ammo, and a FROZEN DAQUIRI!!

On Fri, Jun 13, 2008 at 09:38:18AM -0400, Denis Bueno wrote:

On Fri, Jun 13, 2008 at 09:26, Denis Bueno [off-list ref] wrote:

quoted

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.

That makes more sense.

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.

-- 
Luciano Rocha [off-list ref]
Eurotux Informática, S.A. <http://www.eurotux.com/>

"Denis Bueno" [off-list ref] writes:

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'

This depends on how git was build (on compile time configuration).
git-instaweb.sh (source of git-instaweb) has

        PERL='@@PERL@@'

which is set to value of $PERL_PATH (or, to be more exact, its squoted
version) during building git-instaweb.  So you can simply use

  $ make PERL_PATH=/usr/bin/perl
  # make PERL_PATH=/usr/bin/perl install

or whatever, or you can use ./configure script

  $ make configure
  $ ./configure --with-perl=/usr/bin/perl


On Linux for example the path to perl is set explicitely, instead of
using "/usr/bin/env perl" construct.  The 'env' construct has the
following disadvantages:
 - it uses first Perl find in your $PATH, so if git works for you or
   don't work depends on user's personal configuration
   (reproductability, convenience and security).
 - AFAIK it doesn't allow to pass switches to Perl


P.S. Check if you have new enough Perl (there are problems with
Unicode support in old Perl), and if you have CGI.pm new enough
installed for gitweb.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

On Fri, Jun 13, 2008 at 10:21, Luciano Rocha [off-list ref] 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?

-- 
 Denis

Asheesh Laroia wrote:

On Fri, 13 Jun 2008, Chris Ridd wrote:

quoted

Denis Bueno wrote:

quoted

On Fri, Jun 13, 2008 at 09:46, Asheesh Laroia [off-list ref] 
wrote:

quoted

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)?

Cheers,

Chris

On Fri, Jun 13, 2008 at 10:42, Chris Ridd [off-list ref] wrote:

Asheesh Laroia wrote:

quoted

On Fri, 13 Jun 2008, Chris Ridd wrote:

quoted

Denis Bueno wrote:

quoted

On Fri, Jun 13, 2008 at 09:46, Asheesh Laroia [off-list ref]
wrote:

quoted

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)?

The issue seems to be one of the way bash is treating quotes.  It
apparently is trying to find the *command* "/usr/bin/env perl" and not
executing the command "/usr/bin/env" with a first argument of "perl".

See my message to Luciano moments ago.

-- 
 Denis

On Fri, Jun 13, 2008 at 10:39:11AM -0400, Denis Bueno wrote:

On Fri, Jun 13, 2008 at 10:21, Luciano Rocha [off-list ref] wrote:

quoted

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 [off-list ref]
Eurotux Informática, S.A. <http://www.eurotux.com/>

Luciano Rocha [off-list ref] writes:

On Fri, Jun 13, 2008 at 10:39:11AM -0400, Denis Bueno wrote:

quoted

On Fri, Jun 13, 2008 at 10:21, Luciano Rocha [off-list ref] wrote:

quoted

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...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

On Fri, Jun 13, 2008 at 08:32:20AM -0700, Jakub Narebski wrote:

Luciano Rocha [off-list ref] writes:

quoted

On Fri, Jun 13, 2008 at 10:39:11AM -0400, Denis Bueno wrote:

quoted

On Fri, Jun 13, 2008 at 10:21, Luciano Rocha [off-list ref] wrote:

quoted

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...

Oh. Then it gets ugly. Can't just "perl" be used? Instead of
"/usr/bin/env perl"?

Otherwise...
if [ -x "$PERL" ]; then
	"$PERL" ...
else
	$PERL ...
fi

-- 
Luciano Rocha [off-list ref]
Eurotux Informática, S.A. <http://www.eurotux.com/>