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

From Corey Huinker
Subject Re: Add SHELL_EXIT_CODE to psql
Date
Msg-id CADkLM=fQBS=xEt7ZTMi3HRfaiFZdHDWKc3EJCp1V9St3vtm+5g@mail.gmail.com
Whole thread Raw
In response to Re: Add SHELL_EXIT_CODE to psql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add SHELL_EXIT_CODE to psql  (Maxim Orlov <orlovmg@gmail.com>)
Re: Add SHELL_EXIT_CODE to psql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Mar 10, 2023 at 3:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'm okay with adopting bash's rule, but then it should actually match
bash --- signal N is reported as 128+N, not -N.

128+N is implemented.

Nonzero pclose errors of any kind will now overwrite an existing exit_code.

I didn't write a formal test for the signals, but instead tested it manually:

[310444:16:54:32 EDT] corey=# \! sleep 1000
-- in another window, i found the pid of the sleep command and did a kill -9 on it
[310444:16:55:15 EDT] corey=# \echo :SHELL_EXIT_CODE
137

137 = 128+9, so that checks out.

The OS-specific regression test has been modified. On Windows systems it attempts to execute "CON", and on other systems it attempts to execute "/". These are marginally better than "nosuchcommand" in that they should always exist on their host OS and could never be a legit executable. I have no opinion whether the test should live on past the development phase, but if it does not then the 0001 patch is not needed.
  
Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Schema variables - new implementation for Postgres 15
Next
From: Tomas Vondra
Date:
Subject: Re: logical decoding and replication of sequences, take 2