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-25 18:47 UTC ====================================================================== Summary: clarify/define the meaning of n<&n and m>&m redirections ======================================================================
---------------------------------------------------------------------- (0007294) hvd (reporter) - 2025-10-25 18:47 https://www.austingroupbugs.net/view.php?id=1913#c7294 ---------------------------------------------------------------------- Re: https://www.austingroupbugs.net/view.php?id=1913#c7293 > Why? Is there any shell that would report an error on 3<&4 if 4 was open in O_WRONLY? I've not come across any myself where both 3<&4 and 3>&4 were not both just doing just a dup2(4, 3) or equivalent. This is not the subject of this bug, this wording came about because of https://www.austingroupbugs.net/view.php?id=1536. Previously, the wording specified "if the digits in word do not represent a file descriptor already open for input, a redirection error shall result" and likewise for >&. That wording was adjusted to no longer require that to reflect the reality that shells just did not implement that. The previously required behaviour continues to be permitted, making it so that POSIX doesn't suddenly start saying "echo error <&2" is just peachy when the only effect over >&2 would be to confuse readers. 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 2025-10-23 21:17 stephane Note Added: 0007292 2025-10-23 21:24 stephane Note Added: 0007293 2025-10-25 18:47 hvd Note Added: 0007294 ======================================================================
