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-09-25 11:34 UTC ====================================================================== Summary: clarify/define the meaning of n<&n and m>&m redirections ======================================================================
---------------------------------------------------------------------- (0007277) geoffclare (manager) - 2025-09-25 11:34 https://www.austingroupbugs.net/view.php?id=1913#c7277 ---------------------------------------------------------------------- Suggested Interpretation response ------------------------ The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- As the submitter points out, the wording in the standard "one input file descriptor from another" implies that they are two different file descriptors, and so the behavior of n<&n is currently unspecified (implicitly). Likewise for m>&m. There is an example in XRAT C.2.9.3 Lists (under "Asynchronous AND-OR Lists") which shows that the intention is for <&0 (and therefore also 0<&0) to be a no-op, but since this is non-normative it does not affect the requirements of the standard. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- On page 2497 line 81097-81118 replace sections 2.7.5 and 2.7.6 with:<blockquote><b>2.7.5 Duplicating a File Descriptor</b><blockquote>The redirection operators:<pre><b>[</b><i>n</i><b>]</b><&<i>word</i></pre>and:<pre><b>[</b><i>n</i><b>]</b>>&<i>word</i></pre> shall duplicate one input file descriptor or output file descriptor, respectively, from another, or shall close one. If <i>word</i> consists of one or more decimal digits which evaluate to a value not equal to <i>n</i> (or 0 or 1, respectively, if <i>n</i> is not specified), the file descriptor denoted by <i>n</i> (or standard input or standard output, respectively, if <i>n</i> is not specified) shall be made to be a copy of the file descriptor denoted by <i>word</i>. If the digits in <i>word</i> do not represent an already open file descriptor, a redirection error shall result (see [xref to 2.8.1]). If the file descriptor denoted by <i>word</i> represents an open file descriptor that is not open for input or open for output, respectively, a redirection error may result. If <i>word</i> and <i>n</i> evaluate to the same open file descriptor, or if <i>n</i> is not specified and <i>word</i> evaluates to 0 or 1, respectively, no duplication shall occur. If the shell would have closed the file descriptor because it was opened using [xref to exec] and has a value greater than 2, when the redirection is being performed in a command that will execute a non-built-in utility the file descriptor shall instead remain open when the utility is executed. If <i>word</i> evaluates to '-', then file descriptor <i>n</i> (or standard input or standard output, respectively, if <i>n</i> is not specified) shall be closed. Attempts to close a file descriptor that is not open shall not constitute an error. If <i>word</i> evaluates to something else, the behavior is unspecified.</blockquote></blockquote>and renumber 2.7.7 to 2.7.6. On page 2506 line 81501 section 2.9.3.1 Asynchronous AND-OR Lists, change:<blockquote>If, and only if, job control is disabled, the standard input for the subshell in which an asynchronous AND-OR list is executed shall initially be assigned to an open file description that behaves as if <b>/dev/null</b> had been opened for reading only. This initial assignment shall be overridden by any explicit redirection of standard input within the AND-OR list.</blockquote>to:<blockquote>If, and only if, job control is disabled, the standard input for the subshell in which an asynchronous AND-OR list is executed shall be assigned to an open file description that behaves as if <b>/dev/null</b> had been opened for reading only, except that: <ul> <li>This assignment shall not be performed if there is any explicit redirection of standard input, other than <tt><&0</tt> (or equivalent), within the AND-OR list.</li> <li>This assignment need not be performed if the AND-OR list is within a compound command and either there is any explicit redirection, other than <tt><&0</tt> (or equivalent), of the compound command's standard input or the compound command follows the control operator '|'.</li> </ul></blockquote> On page 3893 line 135146 section C.2.7.5, change the section heading:<blockquote><i>Duplicating an Input File Descriptor</i></blockquote>to:<blockquote><i>Duplicating a File Descriptor</i></blockquote> After page 3893 line 135152 section C.2.7.5, add a paragraph:<blockquote>If <i>word</i> and <i>n</i> evaluate to the same open file descriptor, the operation is a no-op except in shells which set the close-on-exec flag for file descriptors greater than 2 opened using [xref to exec]. In these shells, a redirection of this form can be used to clear the close-on-exec flag so that the file descriptor will remain open when executing a non-built-in utility. For example:<pre>exec 3<infile 4>outfile utility 3<&3 4>&4</pre>One use for this feature, together with <i>command</i> and <i>exec</i>, is to differentiate between utility and redirection errors. For example:<pre>( command exec 3<infile 4>outfile || exit 128; utility 3<&3 4>&4 ) case $? in 0) # success ;; 128) # redirection error ... ;; *) # utility error ... ;; esac</pre>(This assumes <i>utility</i> is known not to use 128 as an exit status and that the shell does not detect an internal error such as resource exhaustion.)</blockquote> On page 3893 line 135155-135158, delete section C.2.7.6 Duplicating an Output File Descriptor On page 3894 line 135159, change section number C.2.7.7 to C.2.7.6 On page 3901 line 135455 section C.2.9.3 Lists, change:<blockquote>Since the connection of the input to the equivalent of <b>/dev/null</b> is considered to occur before redirections, the following script would produce no output:<pre>exec < /etc/passwd cat <&0 & wait </pre></blockquote>to:<blockquote>The assignment of standard input from an open file description that behaves like <b>/dev/null</b> is not overridden by an explicit <tt><&0</tt> redirection because this redirection does not perform a duplication and thus has no effect on where standard input comes from. This was the original Korn Shell behavior but was not clearly required by versions of this standard earlier than Issue 8 TC1, although in all those versions there was rationale stating that the following script would produce no output:<pre>exec < /etc/passwd cat <&0 & wait</pre></blockquote> 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 ======================================================================
