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, 21:39 UTC
Message-ID
<20170113213900.GA25890@starla>
In-Reply-To
<xmqq37gmhgpn.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> wrote:
Show 21 quoted lines
> 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, we keep "use warnings" other people may use, at least. No harm in keeping that in top-level scripts, I guess.

Show 6 quoted lines
> 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.
Previous: Junio C HamanoNext: Jeff King
Message 17 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.