Re: [COMMITTERS] pgsql: Replace duplicate_oids with Perl implementation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Replace duplicate_oids with Perl implementation
Date
Msg-id 5386.1384125140@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Replace duplicate_oids with Perl implementation  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: [COMMITTERS] pgsql: Replace duplicate_oids with Perl implementation  (Robert Haas <robertmhaas@gmail.com>)
Re: [COMMITTERS] pgsql: Replace duplicate_oids with Perl implementation  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.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?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Next
From: Tom Lane
Date:
Subject: Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist