Re: Non-portable shell code in pg_upgrade tap tests - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Non-portable shell code in pg_upgrade tap tests
Date
Msg-id 20180722072904.GA3951499@rfd.leadboat.com
Whole thread Raw
In response to Re: Non-portable shell code in pg_upgrade tap tests  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Non-portable shell code in pg_upgrade tap tests  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: pgbench: improve --help and --version parsing
Next
From: Dmitry Dolgov
Date:
Subject: Re: pgbench-ycsb