From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: Victor Wagner <vitus@wagner.pp.ru>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Non-portable shell code in pg_upgrade tap tests
Date: Sun, 22 Jul 2018 14:53:51 -0400
Message-ID: <24717.1532285631@sss.pgh.pa.us> (raw)
In-Reply-To: <20180722173857.GA3998719@rfd.leadboat.com>
References: <20180720153820.69e9ae6c@fafnir.local.vm>
<17833.1532096747@sss.pgh.pa.us>
<20180720175508.07776219@fafnir.local.vm>
<20015.1532099353@sss.pgh.pa.us>
<20180722072904.GA3951499@rfd.leadboat.com>
<6519.1532270763@sss.pgh.pa.us>
<20180722173857.GA3998719@rfd.leadboat.com>
Noah Misch <noah@leadboat.com> writes:
> On Sun, Jul 22, 2018 at 10:46:03AM -0400, Tom Lane wrote:
>> The pg_upgrade makefile does in fact use $(SHELL), so it will default to
>> whatever shell configure used.
> It will not, because we don't set $(SHELL) anywhere. $(SHELL) is not @SHELL@.
> In our makefiles, $(SHELL) is always /bin/sh, the GNU make default.
Oh! Hm, I wonder whether we shouldn't do that, ie add SHELL = @SHELL@
to Makefile.global.in.
A quick trawl of the buildfarm logs says most of our animals compute
SHELL = /bin/sh anyway, and so would be unaffected. There's a sizable
population that find /bin/bash though, and one active critter that finds
/bin/ksh.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, noah@leadboat.com, vitus@wagner.pp.ru
Subject: Re: Non-portable shell code in pg_upgrade tap tests
In-Reply-To: <24717.1532285631@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox