On Monday, July 28, 2025, Jacob Champion <jacob.champ...@enterprisedb.com> wrote:
> On Mon, Jul 28, 2025 at 2:42 PM David G. Johnston > <david.g.johns...@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.
