Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fhIKC-00060p-6D for pgsql-hackers@arkaria.postgresql.org; Sun, 22 Jul 2018 17:39:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fhIK8-00043D-K1 for pgsql-hackers@arkaria.postgresql.org; Sun, 22 Jul 2018 17:39:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fhIK8-000435-4w for pgsql-hackers@lists.postgresql.org; Sun, 22 Jul 2018 17:39:12 +0000 Received: from mail-pg1-x533.google.com ([2607:f8b0:4864:20::533]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fhIJz-00088W-J2 for pgsql-hackers@postgresql.org; Sun, 22 Jul 2018 17:39:11 +0000 Received: by mail-pg1-x533.google.com with SMTP id g2-v6so10556007pgs.6 for ; Sun, 22 Jul 2018 10:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=pyr0uBA2RU/Rmvz8DdJ/zsTyXVc3yt4AcSch5yEje5g=; b=WjXe9/OaTCBHHoXXkUgVecMTmxHmXrfocj5iR14tWsM39duzG3o86Qgd2FqLoBvbER zZqZvsKqYA24sdpks4pqg29nk/EdbA+V+G2LMWa+W8w2oxdnh9f5lDK8jmYA1hjZWyUI NQOH1MVCqgijWNv2QE5m5rByii531xcaHyLK8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=pyr0uBA2RU/Rmvz8DdJ/zsTyXVc3yt4AcSch5yEje5g=; b=rYUKkuGg/bmBAL3Ku05BpQ5ra5krF8xa9Lf7cDeFd2KRnM61gEBKSvX9+cYfCNR4tr AdM73Hu63t95KyX8db6hYPksfTxjLbJK8i5lhmRF63T4X9t811C3AtxXqmKHN0nfIHof JcKD/7WgoEkd9k/IEgEdG2EV/fU00hSQixRLG8WDulQl6gXhslNX/em3z2julOZI9SFQ DhS6gMqDD6n1cnSClVZGo3+Lzdmym6Qa6+sU0kfpL7BXDQ1+ifg4sR0S8ATzF2hgmEcJ Jf/EvJ0GCnO3Gqtt4hSsElBCGG9DwgwhJZISj1xdedyJkR2OFyxZPSBv9QevPjBsEECu sQlg== X-Gm-Message-State: AOUpUlF6QabneuXzJs+z3OBijNlZ3wTzT+dvTTCtBYYouSju0WC+vY0A eeWfZtBYVwU7opYyjQMDh5Ejz804Smc= X-Google-Smtp-Source: AAOMgpdwgxGP6AIyB7CEI16R8STC3PMpUa41aDB/CbmupshMGh5ICIdMzxIKtwzHcv79bbAFNXC1gg== X-Received: by 2002:a62:843:: with SMTP id c64-v6mr10134565pfd.14.1532281139846; Sun, 22 Jul 2018 10:38:59 -0700 (PDT) Received: from rfd.leadboat.com (c-73-158-248-138.hsd1.ca.comcast.net. [73.158.248.138]) by smtp.gmail.com with ESMTPSA id j71-v6sm10766697pgd.23.2018.07.22.10.38.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jul 2018 10:38:58 -0700 (PDT) Date: Sun, 22 Jul 2018 10:38:57 -0700 From: Noah Misch To: Tom Lane Cc: Victor Wagner , pgsql-hackers Subject: Re: Non-portable shell code in pg_upgrade tap tests Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6519.1532270763@sss.pgh.pa.us> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, Jul 22, 2018 at 10:46:03AM -0400, Tom Lane wrote: > Noah Misch writes: > > 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 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. > The bigger picture here is that it's worth maintaining a common coding > style in this script. Randomly using `...` in some places and $(...) > in others just increases the reader's cognitive load, as does spelling > conditional blocks in multiple styles. So I'd have felt these changes > were appropriate on style grounds even if there were no portability > complaint. For 986127e narrowly, I agree. However, I do want folks able to use $(...) where it saves backslashes; that's more valuable than `...` uniformity. For commit 0426932, as the comment above the changed code indicates, the conditional blocks are copies of "configure" code. Consistency with their source was more valuable than style, particularly since the code is security-critical.