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
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 |