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 20:43 UTC ====================================================================== Summary: clarify/define the meaning of n<&n and m>&m redirections ======================================================================
---------------------------------------------------------------------- (0007120) larryv (reporter) - 2025-03-13 20:43 https://www.austingroupbugs.net/view.php?id=1913#c7120 ---------------------------------------------------------------------- https://www.austingroupbugs.net/view.php?id=1913#c7112:<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.</blockquote>Why not? Is it because the redirections can't be absolutely guaranteed to succeed, as Geoff mentioned on the mailing list?<blockquote>If it is a no-op then it can't fail. So the only possible failure case would be in the "remain open" requirement. In practice this will involve calling fcntl() to clear the FD_CLOEXEC flag, which could indeed fail because of something like resource exhaustion, but I don't see that it increases the likelihood of internal shell failure significantly. Any command execution can fail within the shell because of resource exhaustion (e.g. fork() failure) before it gets as far as doing the exec.</blockquote>https://www.mail-archive.com/[email protected]/msg13640.html<blockquote>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.</blockquote>I don't think the standard should mention your use case at all.<blockquote>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.</blockquote>Alright. The readers I had in mind were application developers who might otherwise assume that n<&n serves no purpose whatsoever. 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 ======================================================================
