patchBuild: make PERL_PATH = /usr/bin/env perl

This should make PERL_PATH more robust, as some systems may have multiple version of perl installed.

Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
 Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Michael Witten <mfwitten@MIT.EDU> writes:

If you insist, you can do so from your "make" command line, but I'd prefer the default configuration as vanilla as possible.

I notice that both git-svn.perl and git-relink.perl begin with "#!/usr/bin/env perl", and I think that is a mistake. The #! line is rewritten by Makefile, and there is no reason to write a "/usr/bin/env" ugliness there in the source. Not that it hurts, as it is blown away when Makefile rewrites it to "#!$(PERL_PATH)", but it still looks ugly.

On 31 May 2008, at 3:55 PM, Junio C Hamano wrote:

The main trouble I've run into is with multiple versions of perl installed. For instance, it is unadvisable to overwrite the Mac OS X provided perl distribution. Consequently, custom installations are usually put into /usr/local (also, MacPorts install everything into /opt/local).

This means that a 'vanilla' configuration may not (most likely will not) make use of the perl distribution that is actually employed by the user.

This matters, because some tools like git-send-email require extra CPAN modules such as Net::SMTP::SSL, which won't be found unless git has been configured with a custom PERL_PATH.

It would seem to me that something like '/usr/bin/env perl' is slightly more vanilla in the sense that it can handle more cases.

Perhaps the Makefile can be smarter about guessing the right path?

Sincerely, Michael Witten

Michael Witten <mfwitten@MIT.EDU> writes:

There's also the case where perl simply isn't available in /usr/bin, but is somewhere else.

Perhaps something like this?

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

"env" is Ok to make the same scripts you have privately in your $HOME/bin/ (which is mounted across different platforms) work with perl or python or whatever from different places, but it is very unsuitable for scripts that are meant to be installed per machine, such as ours, for use by many people.

If you do not have (or want to use) common programs at usual place, you tell "make" where they are, and the resulting scripts will use the same program for everybody. That way, you don't have to worry about confusing people by having scripts use different perl depending on who they are, and by failing for some people and working for others.

You _can_ use "/usr/bin/env" for your own build and I won't stop you, but please don't tell me to ship such ugliness in the default Makefile. We will not do SHELL_PATH = $(shell which sh) either, ever.

By the way, "which" is probably Ok when you know there _is_ an instance of the program somewhere on the $PATH, but be careful if you suspect there might not be any. Depending on whose "which" it is, it may not exit with non-zero status nor be silent on the standard output. If you are shooting for portability, don't use it in your scripts, ever. Also "type" is not much better either ("type -p" is a bash-ism).

Probably the closest to the most portable would be "command -v"; this is a POSIXly kosher way and seems to be Ok with /bin/ksh and OpenBSD /bin/sh as well, not just bash and dash.

On Sat, May 31, 2008 at 2:34 PM, Michael Witten <mfwitten@mit.edu> wrote:

If you do this, you will have to modify the perl scripts to remove the -w flag from their hash-bang line. "/usr/bin/env perl -w" does not seem to do the expected thing.

Insofar as compatibility is concerned, perl's -w flag is equivalent to the 'use warnings' language pragma, which has been supported since 5.6 (circa 2000). Seeing as perl's Unicode support did not really mature until 5.8, I imagine that adding the 'use warnings' pragma and doing away with the -w flag would be a reasonable approach to take.

Regards,

David -- David Christensen End Point Corporation david@endpoint.com