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
Type:                       Enhancement Request
Severity:                   Editorial
Priority:                   normal
Status:                     New
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:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2025-03-12 03:33 UTC
Last Modified:              2025-03-13 02:41 UTC
====================================================================== 
Summary:                    clarify/define the meaning of n<&n and m>&m
redirections
====================================================================== 

---------------------------------------------------------------------- 
 (0007112) calestyo (reporter) - 2025-03-13 02:41
 https://www.austingroupbugs.net/view.php?id=1913#c7112 
---------------------------------------------------------------------- 
<blockquote>The standard does not exist for your personal benefit, so I do not
think it should bless your highly specific use case.</blockquote>
I don't think I was asking to change it to "my personal benefit" (actually my
own use case doesn't need FDs > 2, so I'm already happy with that.).


<blockquote>
However, it would make sense to briefly mention the closing-high-FDs behavior as
motivation. Something along the lines of Geoff's wording in the thread would be
more than sufficient:
</blockquote>
What I at least would want to avoid is that people might ever come across this
issue or the corresponding mailing list thread and assume that this is now the
way to portably differentiate between utility non-zero exit status and
redirection error, when wouldn't be really the case.

If you don't think it is, fine for me,... we can still make the change here, but
should also mention that this cannot be expected to portably allow the above.

If you think it is and if you think that "briefly mentioning the
closing-high-FDs behavior as motivation" is enough to also make sure that this
is understood by any shell implementer, then I'm all good.
My idea to mention the deeper purpose was merely for the case that would be
needed. 

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


  • [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
      • 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
              • ... 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
                • ... Steffen Nurpmeso via austin-group-l at The Open Group
                • ... Chet Ramey via austin-group-l at The Open Group

Reply via email to