View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001954 | 1003.1(2024)/Issue8 | Shell and Utilities | public | 2025-11-07 20:40 | 2025-11-08 11:13 |
| Reporter | stephane | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Enhancement Request |
| Status | New | Resolution | Open | ||
| Name | Stephane Chazelas | ||||
| Organization | |||||
| User Reference | |||||
| Section | trap utility | ||||
| Page Number | 2565 | ||||
| Line Number | 83714-83716 | ||||
| Interp Status | |||||
| Final Accepted Text | |||||
| Summary | 0001954: please allow shells to unignore signals | ||||
| Description | The specification of the trap utility has: <<< Signals that were ignored on entry to a non-interactive shell cannot be trapped or reset, although no error need be reported when attempting to do so. An interactive shell may reset or catch signals ignored on entry. >>> In this day and age, that requirement is unhelpful and annoying. That means one has to resort to things like perl or shells that ignore that requirement to work around it. For example, to make sure SIGPIPE is not ignored: #! /bin/sh -
if [ -n "$RESTORED_SIGPIPE" ]; then
unset -v RESTORED_SIGPIPE
else
RESTORED_SIGPIPE=1 exec perl -e '$SIG{PIPE} = "DEFAULT"; exec @ARGV' -- "$0" "$@"
fiI guess POSIX introduced that requirement because that's what the Bourne shell or ksh88 did back then, and they likely did it because they were written before BSD job control was invented in the 80s, so handling of "background" jobs was done by ignoring SIGINT/SIGQUIT, and restoring their disposition in those jobs would defeat that. Nowadays, we should no longer need that. In any case, even back then that requirement would not make sense in an interactive shell which likely explains why POSIX doesn't mandate it there. So unless there's another good reason that still holds today (but I doubt so, zsh has been ignoring that for 35 years and I don't think anyone ever complained), I'd suggest dropping it. That comes back regularly in usenet or stackexchange discussions, with one of the work arounds being to switch shell to zsh. | ||||
| Desired Action | Change that paragraph to something like: <<< Requests to change the disposition of signals that were ignored on entry of the shell may be silently ignored by the trap utility. Traps shall remain in place for a given shell until explicitly changed with another trap command. >>> And maybe add a rationale section with historical information as to why some shells may still be doing it. | ||||
| Tags | No tags attached. | ||||
|
|
Sorry, I removed the "Traps shall remain in place for a given shell until explicitly changed with another trap command" part from the quoting text as it was not relevant to this issue but forgot to remove it from the proposed resolution. It should just be: <<< Requests to change the disposition of signals that were ignored on entry of the shell may be silently ignored by the trap utility. >>> Note it's related to and extends 0000751. The behaviour Geoff objected to there in historical shell implementations was likely there for the same reason they refused un-ignoring signals ignored on startup. |
|
|
For the record, I have spent a few hours looking for a rationale for that requirement. The only thing I found was that it was what the Bourne shell did (and the Korn shell inherited it). ChatGPT made a somewhat compelling argument: <<< 1. Fundamental Principle: Child Should Respect Parent’s Signal Policy The main rationale comes from the long-standing UNIX convention that a process must not silently override its inherited signal dispositions unless there’s a compelling reason. When a process is launched, the parent’s signal dispositions reflect deliberate decisions about how that process and its descendants should behave in response to asynchronous events (interrupts, termination requests, etc.). For instance: A parent program that sets SIGINT (Ctrl-C) to SIG_IGN is saying “don’t let Ctrl-C interrupt me or anything I spawn.” A system daemon, or a pipeline component, might ignore SIGPIPE to prevent cascaded terminations. If a shell script could re-enable those signals, it would be violating a fundamental contract: Children should inherit and honour their parent’s signal ignore state. >>> Though all the references to that "long-standing UNIX convention" it gave me were all made-up and it admitted not being able to give me a verifiable one. One of my issues here is the shell deciding it knows better than the user if a signal disposition should be changed. No other programming language does AFAIK. |
|
|
(ChatGPT transcript at https://chatgpt.com/share/690f033f-1878-800a-9714-5008c7597fa6 in case anyone cares and would like to follow-up there) |
