A NOTE has been added to this issue. 
====================================================================== 
https://www.austingroupbugs.net/view.php?id=1913 
====================================================================== 
Reported By:                calestyo
Assigned To:                
====================================================================== 
Project:                    1003.1(2024)/Issue8
Issue ID:                   1913
Category:                   Shell and Utilities
Tags:                       tc1-2024
Type:                       Enhancement Request
Severity:                   Editorial
Priority:                   normal
Status:                     Interpretation Required
Name:                       Christoph Anton Mitterer 
Organization:                
User Reference:             Shell & Utilities 
Section:                    2.7.5, 2.7.6 
Page Number:                2497 
Line Number:                81097-81118 
Interp Status:              Proposed 
Final Accepted Text:       
https://www.austingroupbugs.net/view.php?id=1913#c7277 
Resolution:                 Accepted As Marked
Fixed in Version:           
====================================================================== 
Date Submitted:             2025-03-12 03:33 UTC
Last Modified:              2025-10-23 16:46 UTC
====================================================================== 
Summary:                    clarify/define the meaning of n<&n and m>&m
redirections
====================================================================== 

---------------------------------------------------------------------- 
 (0007291) hvd (reporter) - 2025-10-23 16:46
 https://www.austingroupbugs.net/view.php?id=1913#c7291 
---------------------------------------------------------------------- 
Currently, in multiple shells, even the non-close-on-exec shells, 8<&8 is not a
no op if fd 8 was closed: it results in an error exactly as 0<&8 would. By my
reading of the proposed wording, in shells that do not set close-on-exec, this
would be required to be silently accepted, and in shells that do set
close-on-exec, this would effectively be required to result in an error (an
error is the natural consequence of the required behaviour). This inconsistency
does not look useful to me. This should be accepted in all shells, an error in
all shells, or unspecified whether it results in an error, not tied to
close-on-exec. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2025-03-12 03:33 calestyo       New Issue                                    
2025-03-12 07:00 larryv         Note Added: 0007111                          
2025-03-13 02:41 calestyo       Note Added: 0007112                          
2025-03-13 16:12 geoffclare     Note Added: 0007115                          
2025-03-13 17:48 calestyo       Note Added: 0007117                          
2025-03-13 20:20 larryv         Note Added: 0007119                          
2025-03-13 20:43 larryv         Note Added: 0007120                          
2025-03-14 09:44 geoffclare     Note Edited: 0007115                         
2025-03-18 12:30 geoffclare     Note Added: 0007125                          
2025-03-20 14:49 geoffclare     Note Edited: 0007115                         
2025-09-25 11:34 geoffclare     Note Added: 0007277                          
2025-10-23 15:34 geoffclare     Note Edited: 0007277                         
2025-10-23 15:36 geoffclare     Note Edited: 0007277                         
2025-10-23 15:37 geoffclare     Status                   New => Interpretation
Required
2025-10-23 15:37 geoffclare     Resolution               Open => Accepted As
Marked
2025-10-23 15:37 geoffclare     Interp Status             => Pending         
2025-10-23 15:37 geoffclare     Final Accepted Text       =>
https://www.austingroupbugs.net/view.php?id=1913#c7277    
2025-10-23 15:38 geoffclare     Tag Attached: tc1-2024                       
2025-10-23 15:52 ajosey         Interp Status            Pending => Proposed 
2025-10-23 15:52 ajosey         Note Added: 0007289                          
2025-10-23 16:46 hvd            Note Added: 0007291                          
======================================================================


          • ... Chet Ramey via austin-group-l at The Open Group
            • ... Geoff Clare via austin-group-l at The Open Group
              • ... Chet Ramey via austin-group-l at The Open Group
              • ... Geoff Clare via austin-group-l at The Open Group
      • R... Harald van Dijk via austin-group-l at The Open Group
        • ... Geoff Clare via austin-group-l at The Open Group
          • ... Harald van Dijk via austin-group-l at The Open Group
            • ... Geoff Clare via austin-group-l at The Open Group
  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group

Reply via email to