Oops, that sample output was from a previous run, should have been: -- SHELL_EXIT_CODE is undefined \echo :SHELL_EXIT_CODE :SHELL_EXIT_CODE -- bad \! \! borp sh: line 1: borp: command not found \echo :SHELL_EXIT_CODE 127 -- bad backtick \set var `borp` sh: line 1: borp: command not found \echo :SHELL_EXIT_CODE 127 -- good \! \! true \echo :SHELL_EXIT_CODE 0 -- play with exit codes \! exit 4 \echo :SHELL_EXIT_CODE 4 \set var `exit 3` \echo :SHELL_EXIT_CODE 3
On Fri, Nov 4, 2022 at 5:08 AM Corey Huinker <corey.huin...@gmail.com> wrote: > > Over in > https://www.postgresql.org/message-id/eaf326ad693e74eba068f33a7f518...@oss.nttdata.com > Justin > Pryzby suggested that psql might need the ability to capture the shell exit > code. > > This is a POC patch that does that, but doesn't touch on the ON_ERROR_STOP > stuff. > > I've added some very rudimentary tests, but haven't touched the > documentation, because I strongly suspect that someone will suggest a > better name for the variable. > > But basically, it works like this > > -- SHELL_EXIT_CODE is undefined > \echo :SHELL_EXIT_CODE > :SHELL_EXIT_CODE > -- bad \! > \! borp > sh: line 1: borp: command not found > \echo :SHELL_EXIT_CODE > 32512 > -- bad backtick > \set var `borp` > sh: line 1: borp: command not found > \echo :SHELL_EXIT_CODE > 127 > -- good \! > \! true > \echo :SHELL_EXIT_CODE > 0 > -- play with exit codes > \! exit 4 > \echo :SHELL_EXIT_CODE > 1024 > \set var `exit 3` > \echo :SHELL_EXIT_CODE > 3 > > > Feedback welcome. >
