From: Patrick Steinhardt <ps@pks.im>
To: Todd Zullinger <tmz@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] global: resolve Perl executable via PATH
Date: Wed, 5 Apr 2023 16:52:40 +0200 [thread overview]
Message-ID: <ZC2LOAwycdaUawxM@ncase> (raw)
In-Reply-To: <ZC2I7CfVzY6Tl7Pk@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]
On Wed, Apr 05, 2023 at 10:42:52AM -0400, Todd Zullinger wrote:
> Patrick Steinhardt wrote:
> > The majority of Perl scripts we carry in Git have a `#!/usr/bin/perl`
> > shebang. This is not a portable location for the Perl interpreter and
> > may thus break on some systems that have the interpreter installed in a
> > different location. One such example is NixOS, where the only executable
> > installed in `/usr/bin` is env(1).
>
> Is there a reason to not set PERL_PATH, which is the
> documented method to handle this? From the Makefike:
>
> # Define PERL_PATH to the path of your Perl binary (usually /usr/bin/perl).
Setting PERL_PATH helps with a subset of invocations where the Makefile
either executes Perl directly or where it writes the shebang itself. But
the majority of scripts I'm touching have `#!/usr/bin/perl` as shebang,
and that path is not adjusted by setting PERL_PATH.
I'd be happy to amend the patch series to only fix up shebangs which
would not be helped by setting PERL_PATH. But if we can make it work
without having to set PERL_PATH at all I don't quite see the point.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-04-05 14:52 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-05 10:10 [PATCH] global: resolve Perl executable via PATH Patrick Steinhardt
2023-04-05 13:35 ` Felipe Contreras
2023-04-05 14:48 ` Patrick Steinhardt
2023-04-05 14:42 ` Todd Zullinger
2023-04-05 14:52 ` Patrick Steinhardt [this message]
2023-04-05 15:54 ` Todd Zullinger
2023-04-05 17:09 ` Felipe Contreras
2023-04-05 17:35 ` Patrick Steinhardt
2023-04-05 18:44 ` Junio C Hamano
2023-04-06 2:27 ` Felipe Contreras
2023-04-05 16:54 ` Jeff King
2023-04-05 17:32 ` Patrick Steinhardt
2023-04-05 18:15 ` Jeff King
2023-04-06 2:18 ` Felipe Contreras
2023-04-06 3:35 ` Jeff King
2023-04-06 8:03 ` Ævar Arnfjörð Bjarmason
2023-04-18 8:59 ` Felipe Contreras
2023-04-06 8:07 ` Patrick Steinhardt
2023-04-05 18:28 ` Kristoffer Haugsbakk
2023-04-05 21:30 ` Eric Wong
2023-04-06 2:16 ` Felipe Contreras
2023-04-06 8:05 ` Ævar Arnfjörð Bjarmason
2023-04-06 3:26 ` Jeff King
2023-04-06 8:19 ` Patrick Steinhardt
2023-04-06 9:36 ` [PATCH] t/lib-httpd: pass PERL_PATH to CGI scripts Jeff King
2023-04-06 16:34 ` Junio C Hamano
2023-04-18 9:04 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZC2LOAwycdaUawxM@ncase \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=tmz@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.