All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Wong <e@80x24.org>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] global: resolve Perl executable via PATH
Date: Wed, 5 Apr 2023 21:30:20 +0000	[thread overview]
Message-ID: <20230405213020.M231170@dcvr> (raw)
In-Reply-To: <d9cfad7caf9ff5bf88eb06cf7bb3be5e70e6d96f.1680689378.git.ps@pks.im>

Patrick Steinhardt <ps@pks.im> wrote:
> diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
> index 755a110bc4..3fe43b8968 100755
> --- a/Documentation/cmd-list.perl
> +++ b/Documentation/cmd-list.perl
> @@ -1,5 +1,6 @@
> -#!/usr/bin/perl -w
> +#!/usr/bin/env perl
>  
> +use warnings;

Fwiw, adding `use warnings' only affects the current scope
(package main), whereas `-w' affects the entire Perl process.

I prefer `-w' since adding `use warnings' everywhere is
annoyingly verbose and I only use 3rd-party code that's
warning-clean.

In *.t test scripts and stuff I intend to be overwritten in
install scripts; I've been using `#!perl -w' as the shebang
as a clear signal that it should be overwritten on install
or or run via `$(PERL) FOO' in a Makefile.

For personal scripts in ~/bin, I've been going shebang-less
and having the following as the first two lines:

	eval 'exec perl -w -S $0 ${1+"$@"}'
	if 0; # running under some shell

(Only tested GNU/Linux and FreeBSD, though).  This (and
`env perl') will fail if distros someday decide to start
using `perl5' as the executable name.


That said, I don't know if anything I've said above is
appropriate for the git project aside from noting the
difference between `-w' and `use warnings'.

  parent reply	other threads:[~2023-04-05 21:30 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
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 [this message]
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=20230405213020.M231170@dcvr \
    --to=e@80x24.org \
    --cc=git@vger.kernel.org \
    --cc=ps@pks.im \
    /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.