git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
EWEric Wong <e@80x24.org>
Date
Jan 13, 2017, 18:52 UTC
Message-ID
<20170113185246.GA17441@starla>
In-Reply-To
<xmqq4m12izmd.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> 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"

> If something we write outselves trigger a false-positive, we can
> work it around with "no warnings;" in the smallest block that
> encloses the offending code in the worst case, or just rephrase it
> in a way that won't trigger a false-positive.
Correct.
Show 7 quoted lines
> If something we _use_ from a third-party is not warnings-clean,
> there is no easy way to squelch them if we use "-w", which is a
> potential downside, isn't it?  I do not know how serious a problem
> it is in practice.  I suspect that the core package we use from perl
> distribution are supposed to be warnings-clean, but we use a handful
> of things from outside the core and I do not know what state they
> are in.

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

Previous: Junio C HamanoNext: Junio C Hamano
Message 15 of 24 in “Use env for all perl invocations”
  1. 0/2 Use env for all perl invocationsPat Pannuto, Jan 12, 2017
  2. 1/2 Convert all 'perl -w' to 'perl' + 'use warnings;'Pat Pannuto, Jan 12, 2017
  3. 2/2 Use 'env' to find perl instead of fixed pathPat Pannuto, Jan 12, 2017
  4. Johannes SixtJan 12, 2017
  5. Pat PannutoJan 12, 2017
  6. Johannes SchindelinJan 12, 2017
  7. Junio C HamanoJan 12, 2017
  8. Pat PannutoJan 12, 2017
  9. Junio C HamanoJan 12, 2017
  10. Eric WongJan 13, 2017
  11. Johannes SchindelinJan 13, 2017
  12. Eric WongJan 13, 2017
  13. Johannes SchindelinJan 13, 2017
  14. Junio C HamanoJan 13, 2017
  15. Eric WongJan 13, 2017
  16. Junio C HamanoJan 13, 2017
  17. Eric WongJan 13, 2017
  18. Jeff KingJan 14, 2017
  19. Eric WongJan 14, 2017
  20. brian m. carlsonJan 14, 2017
  21. Johannes SchindelinJan 13, 2017
  22. Junio C HamanoJan 12, 2017
  23. Pat PannutoJan 12, 2017
  24. Junio C HamanoJan 12, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.