unofficial mirror of meta@public-inbox.org
 help / color / mirror / Atom feed
From: Eric Wong <e@80x24.org>
To: Alyssa Ross <hi@alyssa.is>
Cc: meta@public-inbox.org
Subject: Re: [PATCH] #!/usr/bin/perl -> #!/usr/bin/env perl
Date: Thu, 26 Sep 2019 02:49:38 +0000	[thread overview]
Message-ID: <20190926024938.GA19132@dcvr> (raw)
In-Reply-To: <20190924204312.7875-1-hi@alyssa.is>

Alyssa Ross <hi@alyssa.is> wrote:
> It's much more reasonable to assume that the Perl a user wants to use
> is the one they have in their path, rather than whatever one has been
> installed system-wide by their distribution (if any!).

I used to think that, too...
Nowadays, I would only use "/usr/bin/env perl" for standalone
or standard-library-only scripts; but nothing with
non-standard-library dependencies.

Some general notes:

* Perl will parse the "-w" in a shebang even if it's invoked as
  "perl /path/to/script" without the "-w"

* "-w" is stronger than "use warnings", in that it applies to
  the whole program rather than the scope of "use warnings"

* Different Perl installations can have different modules
  installed for it, so relying on /usr/bin/env can lead
  to surprises + failures when libraries are missing.

* "/usr/bin/env perl" won't take into account "perl5.xx" names
  that dev versions of Perl get installed as by default, so shebang
  rewriting is necessary for anything end users would use, anyways.

* I've been looking into startup time of some scripts, and
  "use warnings" adds more open() syscalls which affects
  performance a miniscule amount (maybe more for Intel CPUs with
  vulnerabilities).  So I might get rid of some "use warnings"
  in those paths rely on "-w" down the line...

Reordering the diffstat slightly...

>  Makefile.PL                   | 3 ++-

Makefile.PL doesn't have the executable bit set, and all the
documentation says to run it as "perl Makefile.PL"

The reason for the shebang is for external tools,
highlighters and stuff like file(1).

>  Documentation/extman.perl     | 3 ++-
>  Documentation/standards.perl  | 3 ++-

Makefile.PL writes a Makefile which sets $(PERL), with an
absolute path to run those files.

>  certs/create-certs.perl       | 2 +-

Documentation in corresponding t/*.t files could be better
about running that and instead recommend "$^X"

>  ci/deps.perl                  | 3 ++-

That's only run via $PERL (which defaults to 'perl')

>  examples/cgit.psgi            | 2 +-
>  examples/highlight.psgi       | 2 +-
>  examples/newswww.psgi         | 2 +-
>  examples/public-inbox.psgi    | 2 +-
>  examples/unsubscribe.psgi     | 3 ++-

>  t/git-http-backend.psgi       | 2 +-

I only had the shebang there for external tools.
Running a .psgi directly via Perl wouldn't work.

"#!/usr/bin/plackup" might work if it was executable,
but I'm not sure if people do that w/o command-line
options.

>  examples/unsubscribe.milter   | 2 +-

That could probably be installed via Makefile using
$(FIXIN) like the rest of the stuff in script/ below
(but not by default).

>  script/public-inbox-compact   | 2 +-
>  script/public-inbox-convert   | 2 +-
>  script/public-inbox-edit      | 2 +-
>  script/public-inbox-httpd     | 2 +-
>  script/public-inbox-index     | 2 +-
>  script/public-inbox-init      | 2 +-
>  script/public-inbox-learn     | 2 +-
>  script/public-inbox-mda       | 2 +-
>  script/public-inbox-nntpd     | 2 +-
>  script/public-inbox-purge     | 2 +-
>  script/public-inbox-watch     | 2 +-
>  script/public-inbox-xcpdb     | 3 ++-
>  script/public-inbox.cgi       | 2 +-

All of these are handled by $(FIXIN) in the Makefile.
I install these on FreeBSD which puts Perl in /usr/local/bin
and never had a problem.

>  scripts/dupe-finder           | 2 +-
>  scripts/import_maildir        | 2 +-
>  scripts/import_slrnspool      | 2 +-
>  scripts/import_vger_from_mbox | 2 +-
>  scripts/slrnspool2maildir     | 2 +-
>  scripts/ssoma-replay          | 3 ++-
>  scripts/xhdr-num2mid          | 2 +-
>  t/check-www-inbox.perl        | 2 +-

None of these are really serious scripts, and if they're run;
it's always via "perl /path/to/script"

>  t/hl_mod.t                    | 2 +-

Oops, there probably shouldn't have a shebang there at all
since none of the other *.t files have it.  I've also seen
"#!perl -w" (no '/' at all) in other projects, but I don't think
it's worth the effort unless some external tools/highlighters
work better with it. I expect "#!/usr/bin/perl -w" to be most
compatible with highlighters and stuff like file(1).

  reply	other threads:[~2019-09-26  2:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24 20:43 [PATCH] #!/usr/bin/perl -> #!/usr/bin/env perl Alyssa Ross
2019-09-26  2:49 ` Eric Wong [this message]
2019-10-01 17:47   ` Alyssa Ross
2019-10-01 20:58     ` Eric Wong
2019-10-02 21:36       ` [PATCH] tests: recommend running create-certs.pl with $^X Alyssa Ross
2019-10-02 23:19         ` Eric Wong

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

  List information: https://public-inbox.org/README

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190926024938.GA19132@dcvr \
    --to=e@80x24.org \
    --cc=hi@alyssa.is \
    --cc=meta@public-inbox.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).