Pat Pannuto <pat.pannuto@xxxxxxxxx> 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.