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=d7H=E_P0gUqgyiBWUUzkL4gx9rQykjKWes8ZuiEFW=EQ@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  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Mar 20, 2023 at 1:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Corey Huinker <corey.huinker@gmail.com> writes:
> 128+N is implemented.

I think this mostly looks OK, but:

* I still say there is no basis whatever for believing that the result
of ferror() is an exit code, errno code, or anything else with
significance beyond zero-or-not.  Feeding it to wait_result_to_exit_code
as you've done here is not going to do anything but mislead people in
a platform-dependent way.  Probably should set exit_code to -1 if
ferror reports trouble.

Agreed. Sorry, I read your comment wrong the last time or I would have already made it so.
 

* Why do you have wait_result_to_exit_code defaulting to return 0
if it doesn't recognize the code as either WIFEXITED or WIFSIGNALED?
That seems pretty misleading; again -1 would be a better idea.

That makes sense as well. Given that WIFSIGNALED is currently defined as the negation of WIFEXITED, whatever default result we have here is basically a this-should-never-happen. That might be something we want to catch with an assert, but I'm fine with a -1 for now.
 
Attachment

pgsql-hackers by date:

Previous
From: Ted Toth
Date:
Subject: Re: [PATCH] Add <> support to sepgsql_restorecon
Next
From: Greg Stark
Date:
Subject: Re: Commitfest 2023-03 starting tomorrow!