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

Re: [PATCH 0/2] Use env for all perl invocations

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 12, 2017, 08:21 UTC
Message-ID
<xmqqshoolmct.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<CAAnLKaHrGkAkF+kZtrawDSkuhVkvvUZONp6PQj6=3AGoAwFxyw@mail.gmail.com>
Pat Pannuto <pat.pannuto@gmail.com> writes:
> It feels weird to me that the perl path is fixed at
> compile/install-time as opposed to run-time discovery -- this means
> users can't change their perl install without breaking git?

Among the software packages that use interpreters like perl, python, ruby, etc., there are ones that seem to consider that it is a good idea to let "#!/usr/bin/env $language" pick whatever variant [*1*] of the $language that happens to be on end-user's $PATH.

Git does not subscribe to that thought, and it is done for very good reasons.

When you take a popular $language used by many software packages, it is more than likely that one particular end user uses more than one such package written in the same $language. If one assumes that there is one variant of $language such software packages can all use, then $PATH can be tweaked so that the common variant and no other variants of $language can be found and you are done.

However, that is too simplistic in real life. If you are using Git (which wants Perl 5.8 or later with certain libs) and some other software package that needs a much older Perl, there is no such single variant that can be placed on end-user's $PATH. Only when all the other software packages write their she-bang line without "env" and instead point at the exact variant they need, Git can use the "env" to rely on $PATH, but at that point, Git is being overly arrogant. It insists to be special among packages that use the same $language and wants the variant it needs to be on $PATH.

Git knows that the real-world is not simplistic. Git is not arrogant, either. And that is why it does not use "#!/usr/bin/env".

[Footnote]
*1* Here a "variant" of a $language refers to a binary of one
    particular version of the $language, together with libs and
    extensions it uses that are installed on the system.  You
    apparently have two variants, one installed as /usr/bin/perl,
    the other as /usr/local/bin/perl.
Previous: Pat Pannuto
Message 24 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.