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

2 messages, 2 authors, 2017-01-13 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2017-01-13 20:07:19

Eric Wong [off-list ref] writes:
Junio C Hamano [off-list ref] wrote:
quoted
Eric Wong [off-list ref] writes:
quoted
Pat Pannuto [off-list ref] wrote:
quoted
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.

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

From: Eric Wong <hidden>
Date: 2017-01-13 21:39:05

Junio C Hamano [off-list ref] wrote:
Eric Wong [off-list ref] writes:
quoted
Junio C Hamano [off-list ref] wrote:
quoted
Eric Wong [off-list ref] writes:
quoted
Pat Pannuto [off-list ref] wrote:
quoted
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, we keep "use warnings" other people may use, at least.
No harm in keeping that in top-level scripts, I guess.
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).
Agreed, I'd definitely prefer to move towards the basic eval/die
construct without relying on a bundled 3rd-party mechanism.
But we might need a migration path for out-of-tree users of
Git.pm (if any)...

I'm sure I've agreed this was a path we should be taking in the
past, but did something about it myself.  So yeah, maybe Pat or
somebody else interested can take care of this :)

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help