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).
next prev parent 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).