A NOTE has been added to this issue. ====================================================================== https://www.austingroupbugs.net/view.php?id=1954 ====================================================================== Reported By: stephane Assigned To: ====================================================================== Project: 1003.1(2024)/Issue8 Issue ID: 1954 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: Stephane Chazelas Organization: User Reference: Section: trap utility Page Number: 2565 Line Number: 83714-83716 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2025-11-07 20:40 UTC Last Modified: 2025-11-11 10:25 UTC ====================================================================== Summary: please allow shells to unignore signals ======================================================================
---------------------------------------------------------------------- (0007311) geoffclare (manager) - 2025-11-11 10:25 https://www.austingroupbugs.net/view.php?id=1954#c7311 ---------------------------------------------------------------------- > Though all the references to that "long-standing UNIX convention" it gave me were all made-up Well it certainly is long-standing UNIX convention and the way it was implemented historically in C code was something like:<pre>if (signal(signum, SIG_IGN) != SIG_IGN) signal(signum, handler);</pre> These days it would be done with two sigaction() calls, the first of which only queries the disposition (which signal() could not do). It's also required behaviour for all standard utilities where ASYNCHRONOUS EVENTS says "Default" or specifies "the standard action" for a given signal. (See XCU 1.4 Utility Description Defaults). I always assumed the reason the shell disallows trapping (or resetting) a signal inherited as ignored is so that shell programmers don't need to bother to code some equivalent of the above C code in shell scripts. And given that large numbers of shell scripts rely on this, removing the requirement now would be a bad idea. Issue History Date Modified Username Field Change ====================================================================== 2025-11-07 20:40 stephane New Issue 2025-11-08 08:27 stephane Note Added: 0007302 2025-11-08 08:37 stephane Note Added: 0007303 2025-11-08 11:13 stephane Note Added: 0007304 2025-11-11 10:25 geoffclare Note Added: 0007311 ======================================================================
