The following issue has been REOPENED. ====================================================================== https://www.austingroupbugs.net/view.php?id=1913 ====================================================================== Reported By: calestyo Assigned To: geoffclare ====================================================================== Project: 1003.1(2024)/Issue8 Issue ID: 1913 Category: Shell and Utilities Tags: tc1-2024 Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review 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 ====================================================================== Date Submitted: 2025-03-12 03:33 UTC Last Modified: 2025-10-30 16:41 UTC ====================================================================== Summary: clarify/define the meaning of n<&n and m>&m redirections ======================================================================
---------------------------------------------------------------------- (0007300) geoffclare (manager) - 2025-10-30 16:41 https://www.austingroupbugs.net/view.php?id=1913#c7300 ---------------------------------------------------------------------- New 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 input redirection operator:<pre><b>[</b><i>n</i><b>]</b><&<i>word</i></pre> and output redirection operator:<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> evaluates to the same open file descriptor as <i>n</i> (or 0 or 1, respectively, if <i>n</i> is not specified), 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 a standard utility or a conforming application is executed with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing, except for the case of an <i>exec</i> command with no operands that reopens one or more of those file descriptors, the environment in which the utility or application is executed shall be deemed non-conforming, and consequently the utility or application might not behave as described in this standard. 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> After page 3891 line 135051 section C.2.7, add:<blockquote>When a utility is executed with a redirection, for example:<pre>utility < infile > outfile</pre> it is generally not possible to tell from the exit status of the command whether a non-zero value is caused by failure of the utility or failure of the redirection. One method of differentiating the two is to apply the redirection to a compound command and include a command within the compound command that affects the current shell environment, such as setting a shell variable. For example:<pre>redirection_error=true { redirection_error=false utility } < infile > outfile if "$redirection_error" then # There was a redirection error and utility was not run ... fi</pre></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 an alternative method to the one described in [xref to C.2.7] of differentiating 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 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 2025-10-28 11:59 geoffclare Note Added: 0007295 2025-10-28 12:35 hvd Note Added: 0007296 2025-10-28 15:52 geoffclare Note Added: 0007297 2025-10-28 16:30 hvd Note Added: 0007298 2025-10-30 15:23 geoffclare Note Added: 0007299 2025-10-30 16:41 geoffclare Assigned To => geoffclare 2025-10-30 16:41 geoffclare Status Interpretation Required => Under Review 2025-10-30 16:41 geoffclare Resolution Accepted As Marked => Reopened 2025-10-30 16:41 geoffclare Note Added: 0007300 ======================================================================
