Re: Add SHELL_EXIT_CODE to psql - Mailing list pgsql-hackers

From Isaac Morland
Subject Re: Add SHELL_EXIT_CODE to psql
Date
Msg-id CAMsGm5c3+yLVnSkqb71rnCrMjjNMPGa=qSvf3z3E8Zyr-vYX8w@mail.gmail.com
Whole thread Raw
In response to Re: Add SHELL_EXIT_CODE to psql  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: Add SHELL_EXIT_CODE to psql
List pgsql-hackers
On Sat, 31 Dec 2022 at 16:47, Corey Huinker <corey.huinker@gmail.com> wrote:

I wonder if there is value in setting up a psql on/off var SHELL_ERROR_OUTPUT construct that when set to "off/false" suppresses standard error via appending "2> /dev/null" (or "2> nul" if #ifdef WIN32). At the very least, it would allow for tests like this to be done with standard regression scripts.

Thinking on this some more a few ideas came up:

1. The SHELL_ERROR_OUTPUT var above. This is good for simple situations, but it would fail if the user took it upon themselves to redirect output, and suddenly "myprog 2> /dev/null" works fine on its own but will fail when we append our own "2> /dev/null" to it.

Rather than attempting to append redirection directives to the command, would it work to redirect stderr before invoking the shell? This seems to me to be more reliable and it should allow an explicit redirection in the shell command to still work. The difference between Windows and Unix then becomes the details of what system calls we use to accomplish the redirection (or maybe none, if an existing abstraction layer takes care of that - I'm not really up on Postgres internals enough to know), rather than what we append to the provided command.

pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Add SHELL_EXIT_CODE to psql
Next
From: Nathan Bossart
Date:
Subject: Re: wake up logical workers after ALTER SUBSCRIPTION