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 18:06 UTC ====================================================================== Summary: please allow shells to unignore signals ======================================================================
---------------------------------------------------------------------- (0007315) stephane (reporter) - 2025-11-11 18:06 https://www.austingroupbugs.net/view.php?id=1954#c7315 ---------------------------------------------------------------------- Re: https://www.austingroupbugs.net/view.php?id=1954#c7312 As mentioned above, zsh already does not forbid changing the disposition of signals ignored upon start (and never had AFAIK since the first version from 1990). Even in sh mode, which makes it non-conformant, but also more usable than conformant ones. zsh, when interactive, from testing, appears to restore most if not all signal dispositions to their default, avoiding the common pathological issues with ignored SIGPIPE or SIGCHILD. fish does it even when non-interactive (I don't think that's a good idea when non-interactive though). fish is not (even remotely) POSIX compliant and doesn't claim nor intend to be. I'm not trying to introduce a new feature, just relax or remove a harmful requirement. > And given that large numbers of shell scripts rely on this, removing the requirement now would be a bad idea. Can you please give one example of a real-life shell script that relies on this? I've seen many cases where that gets in the way. I can't think of one where it would be relied upon (except maybe for pre-job control systems from the 80s maybe). I can give references to some examples on unix.stackexchange.com. The latest occurrence and which prompted me to raise that was https://unix.stackexchange.com/a/801140 Do you have a reference to some modern software that does the equivalent of <pre>if (signal(signum, SIG_IGN) != SIG_IGN) signal(signum, handler);</pre> I'm trying to figure out if there's any other reason than to cover the pre-job control handling. 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 2025-11-11 10:50 geoffclare Note Added: 0007312 2025-11-11 18:06 stephane Note Added: 0007315 ======================================================================
