The following issue has been SUBMITTED. ====================================================================== 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-12 03:33 UTC ====================================================================== Summary: clarify/define the meaning of n<&n and m>&m redirections Description: Hey.
This originated from a thread that started at https://collaboration.opengroup.org/operational/mailarch.php?soph=N&action=show&archive=austin-group-l&num=38114&limit=100&offset=100&sid= In short: The motivation was whether it's possible to portably differentiate whether a non-zero exit status originated from a utility or failed redirection on that. The idea was that, with the clarifications from #1879 and assuming that there is at least on exit status which a utility is known not to use, a construct like the following: ( command exec <some redirections> || exit 125; utility ) where the subshell is merely to clean up any redirections, can be used to differentiate between a redirection error (which above would be indicated by 125) or a non-zero exit status from the utility. For file descriptors less than or equal to 2, this should already be guaranteed to work portably, as POSIX demands those to be passed on to the utility. For FDs greater than two, this is no longer guaranteed, though. An idea was brought up by Harald van Dijk, that n<&n and m>&m could be used e.g.: ( command exec <some redirections> || exit 125; utility n<&n... m>&m... ) in order to "manually" pass on on any such FDs. Questions remained: a) Does that behaviour even follow from POSIX (in an obvious way where it's really clear that shells should behave like this, not just some wobbly way) b) Does it even solve the original problem, or could e.g. such a n<&n respectively m>&m fail itself (not e.g. because a file doesn't exist, but because of something like resource exhaustion, etc.) When the original thread was continued a bit later at: https://collaboration.opengroup.org/operational/mailarch.php?soph=N&action=show&archive=austin-group-l&num=38279&limit=100&offset=0&sid= it apparently turned out that n<&n and m>&m redirections are not defined because POSIX uses the wordings: "The redirection operator: [n]<&word shall duplicate one input file descriptor from another" respectively "The redirection operator: [n]>&word shall duplicate one output file descriptor from another" i.e. one from another, implying the two must not be the same, as Geoff Clare pointed out. Desired Action: 1. It shall be clarified whether or not the n<&n and m>&m forms are covered by the current wording of the standard. (One could perhaps also interpret the "one from another" as the "one" being the FD from the utility's PoV, and the "another" being the FD of the same number from the shell's PoV.) 2. If possible - i.e. no conflicting behaviour of shell implementations - it would be nice if the definition could be change in such a way, that it actually allows portably for the goals described above. I have no strong opinion one how this definition should look like, one suggestion on the list was that implementations that the n<&n and m>&m forms shalll be no-ops for implementations which *do* pass on FDs > 2, and for those that don't, it shall have the meaning of explicitly passing the given FD on. It would be even nicer, if the standard mention in a sentence that this is explicitly meant to be usable for the purpose of differentiating between utility and redirection errors. Thanks, Chris. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2025-03-12 03:33 calestyo New Issue ======================================================================
