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-08 08:37 UTC
====================================================================== 
Summary:                    please allow shells to unignore signals
====================================================================== 

---------------------------------------------------------------------- 
 (0007303) stephane (reporter) - 2025-11-08 08:37
 https://www.austingroupbugs.net/view.php?id=1954#c7303 
---------------------------------------------------------------------- 
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. 

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                          
======================================================================


  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group

Reply via email to