Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path

[Junio C Hamano <gitster@pobox.com>]

Eric Wong <e@80x24.org> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>> Eric Wong <e@80x24.org> writes:
>> > Pat Pannuto <pat.pannuto@gmail.com> wrote:
>> >> You may still want the 1/2 patch in this series, just to make things
>> >> internally consistent with "-w" vs "use warnings;" inside git's perl
>> >> scripts.
>> >
>> > No, that is a step back.  "-w" affects the entire process, so it
>> > spots more potential problems.  The "warnings" pragma is scoped
>> > to the enclosing block, so it won't span across files.
>> 
>> OK, so with "-w", we do not have to write "use warnings" in each of
>> our files to get them checked.  It is handy when we ship our own
>> libs (e.g. Git.pm) that are used by our programs.
>
> Yes.  "use warnings" should be in our own libs in case other
> people run without "-w"

Would it mean that we need both anyway?  That is, add missing "use
warnings" without removing "-w" from she-bang line?

> Yes, "-w" will trigger warnings in third party packages.
> Existing uses we have should be fine, and I think most Perl
> modules we use or would use are vigilant about being
> warnings-clean.  If we have to leave off a "-w", there should
> probably be a comment at the top stating the reason:
>
> #!/usr/bin/perl
> # Not using "perl -w" since Foo::Bar <= X.Y.Y is not warnings-clean
> use strict;
> use warnings;
> use Foo::Bar;
> ...

Good.

Speaking of Perl, I recall that somebody complained that we ship
with and do use a stale copy of Error.pm that has been deprecated.
I am not asking you to do so, but we may want to see somebody look
into it (i.e. assessing the current situation, and if it indeed is
desirable for us to wean ourselves away from Error.pm, update our
codepaths that use it).

Thanks.