Re: [COMMITTERS] pgsql: Replace duplicate_oids with Perl implementation
От | Robert Haas |
---|---|
Тема | Re: [COMMITTERS] pgsql: Replace duplicate_oids with Perl implementation |
Дата | |
Msg-id | CA+TgmoYhm6rQtUqsKHK4nfE_hFdSynnhnXqLVcNpxwGzMQuv4A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Replace duplicate_oids with Perl implementation (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [COMMITTERS] pgsql: Replace duplicate_oids with Perl
implementation
|
Список | pgsql-hackers |
On Sun, Nov 10, 2013 at 6:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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? +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
В списке pgsql-hackers по дате отправления: