On Monday, July 28, 2025, Jacob Champion <
jacob.champion@enterprisedb.com> wrote:
On Mon, Jul 28, 2025 at 2:42 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
> I don’t understand calling out sigterm as an exception, the same abort-and-shutdown action happens there too.
RestoreArchivedFile() has a special case for SIGTERM, though?
I don’t see anything calling out sigterm by name. It seems to be handled the same as any other signal exit and, because of the “true” being passed into wait_result_is_any_signal, identically to exit statuses 126-127 as well.
> And in any case signals are turned into exit status values anyway so naming them specifically seems redundant.
Ok, yeah, the C API differentiates this reality since an unhandled signal precludes an exit status from being created. I’m fine with “…unhandled signals causing command termination, or exit statues > 125, result in abort and stop”.
>
> The “Command not found” error is defined by POSIX as exit status 127 making its specification redundant with > 125
I don't think either is redundant from the point of view of the
targeted audience, who may not understand the overlap in the POSIX
specification. "My command returned", "my command died", and "my
command never ran" are interesting cases to have to consider (and I
think it's unfortunate that we can't reliably tell them apart).
wait_result_to_str seems to be sufficient. Sure, the command author can choose to violate conventions, but that’s life.
I don’t really see a point in describing the special meanings ascribed to 126 and 127 here since the error message will handle that should the need arise.
David J.
