From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Geoghegan <pg(at)heroku(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Replace duplicate_oids with Perl implementation |
Date: | 2013-11-12 15:02:06 |
Message-ID: | CA+TgmoYhm6rQtUqsKHK4nfE_hFdSynnhnXqLVcNpxwGzMQuv4A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Sun, Nov 10, 2013 at 6:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> It might be a bit more portable if we replaced the shebang lines on perl
>> scripts with
>> #!/bin/env perl
>
> Perhaps, if we're worried about people keeping perl somewhere other
> than /usr/bin. However, the most likely reason for having a
> /usr/local/bin/perl or whatever is that it's a newer and shinier one
> than what's in /usr/bin. Since we're only interested in bog-standard
> perl, there's no real reason for us to want to pick up the local one.
>
> FWIW, there was a big discussion at Red Hat a few years ago about whether
> to run around and do that to all perl/python scripts, and the outcome of
> the discussion was that using env was deprecated, not encouraged. I don't
> remember the reasoning in detail, but I think the core idea was that if a
> distro knows they ship perl in /usr/bin, then inserting env into the
> equation doesn't do anything but add cycles and failure modes. I'm not
> sure that that argument applies too well to our scenario, but it's out
> there. The particular application to this case might be: what makes
> you so sure env is in /bin?
+1. If we're concerned about non-standard Perl locations, I think the
right way to handle that is to design the makefiles to invoke Perl
scripts using $(PERL) $(srcdir)/whatever.pl; and to make the Windows
build scripts do the equivalent. We are, at least in some places,
already doing that. IMV, the role of the #! line is just to cater to
the less-likely scenario where someone wants to run one of those
scripts outside the build process; if their perl happens to be in the
standard location, they can do that as "./whatever.pl" rather than
"perl whatever.pl". If their perl does not happen to be at that
location, then I think it's anybody's guess what the #! line would
need to be to save those three keystrokes.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-11-12 15:25:13 | pgsql: doc: Fix typo. |
Previous Message | Andres Freund | 2013-11-12 12:05:38 | Re: pgsql: Fix pg_isolation_regress to work outside its build directory. |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-11-12 15:04:11 | Re: Relax table alias conflict rule in 9.3? |
Previous Message | Tom Lane | 2013-11-12 15:00:49 | Re: What's needed for cache-only table scan? |