Re: Add SHELL_EXIT_CODE to psql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Maxim Orlov <orlovmg(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add SHELL_EXIT_CODE to psql
Date: 2023-03-10 20:49:14
Message-ID: 1001466.1678481354@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> The exit status is one byte. I think you should define the status
> variable along the lines of:

> - 0 if successful; or,
> - a positive number 1..255 indicating its exit status. or,
> - a negative number N indicating it was terminated by signal -N; or,
> - 256 if an internal error occurred (like pclose/ferror);

> See bash(1). This would be a good behavior to start with, since it
> ought to be familiar to everyone, and if it's good enough to write/run
> shell scripts in, then it's got to be good enough for psql to run a
> single command in.

I'm okay with adopting bash's rule, but then it should actually match
bash --- signal N is reported as 128+N, not -N.

Not sure what to do about pclose/ferror cases. Maybe use -1?

> I'm not sure why the shell uses 126-127 specially, though..

127 is used similarly by system(3). I think both 126 and 127 might
be specified by POSIX, but not sure. In any case, those are outside
our jurisdiction.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Zhang 2023-03-10 20:58:23 Re: [BUG] pg_stat_statements and extended query protocol
Previous Message Jacob Champion 2023-03-10 20:48:13 Re: zstd compression for pg_dump