Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kXc9l-000172-3R for pgsql-bugs@arkaria.postgresql.org; Wed, 28 Oct 2020 03:29:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kXc9j-0000op-WA for pgsql-bugs@arkaria.postgresql.org; Wed, 28 Oct 2020 03:29:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kXc9j-0000oh-QI for pgsql-bugs@lists.postgresql.org; Wed, 28 Oct 2020 03:29:47 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kXc9h-0007VY-N0 for pgsql-bugs@lists.postgresql.org; Wed, 28 Oct 2020 03:29:46 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1kXc9e-0005pO-6e; Tue, 27 Oct 2020 23:29:42 -0400 Date: Tue, 27 Oct 2020 23:29:42 -0400 From: Bruce Momjian To: Tom Lane Cc: kensuke.okamura@kantei.co.jp, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #16688: psql removes only LF without CR at end of backquotes on windows. Message-ID: <20201028032942.GA21830@momjian.us> References: <16688-c649c7b69cd7e6f8@postgresql.org> <1224124.1603855625@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1224124.1603855625@sss.pgh.pa.us> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, Oct 27, 2020 at 11:27:05PM -0400, Tom Lane wrote: > PG Bug reporting form writes: > > psql removes only LF without CR at end of backquotes on windows. > > Hmm, seems like b654714f9 missed this. psqlscanslash.l has > > fd = popen(cmd, PG_BINARY_R); > ... > /* strip any trailing newline */ > if (cmd_output.len > 0 && > cmd_output.data[cmd_output.len - 1] == '\n') > cmd_output.len--; > > But rather than mess with that newline-chomping code, I'm > inclined to wonder why we're using PG_BINARY_R for input > that we clearly expect to be textual. Most of our other > popen's do not do that. > > Bruce, this seems to date to 98e9775a3 ... don't suppose > you remember that? I see the point about control-Z in text > files, but I wonder how plausible that is for popen cases. It seems safe for popen to use TEXT mode, and it might help with encoding conversion. I don't think I made a popen distinction when I was working in this area. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee