Re: Non-portable shell code in pg_upgrade tap tests
От | Noah Misch |
---|---|
Тема | Re: Non-portable shell code in pg_upgrade tap tests |
Дата | |
Msg-id | 20180722072904.GA3951499@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: Non-portable shell code in pg_upgrade tap tests (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Non-portable shell code in pg_upgrade tap tests
|
Список | pgsql-hackers |
On Fri, Jul 20, 2018 at 11:09:13AM -0400, Tom Lane wrote: > Victor Wagner <vitus@wagner.pp.ru> writes: > > Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Please send a patch. Most of us do not have access to old shells > > > Here it goes. Previous letter was written before fixed tests were > > completed, because this old machine is slow. > > Thanks. Will check on my own dinosaurs, and push if I don't find > a problem. I'd say the right way to fix this is the one specified in https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/The-Make-Macro-SHELL.html, in particular: Using @SHELL@ means that your makefile will benefit from the same improved shell, such as bash or ksh, that was discovered during configure, so that you aren't fighting two different sets of shell bugs between the two contexts. The Solaris 10 /bin/sh can't even run most of "configure", but Solaris 10 also provides /bin/ksh and /usr/xpg4/bin/sh with the usual modern features. ("configure" works on Solaris 10 by finding a good shell and re-execing itself.) Maintaining shell scripts to an even lower common denominator than Autoconf would be a good deal less reliable.
В списке pgsql-hackers по дате отправления: