On 3/13/25 16:15, Austin Group Issue Tracker via austin-group-l at The
Open Group wrote:
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 16:12 UTC
======================================================================
Summary: clarify/define the meaning of n<&n and m>&m
redirections
======================================================================
----------------------------------------------------------------------
(0007115) geoffclare (manager) - 2025-03-13 16:12
https://www.austingroupbugs.net/view.php?id=1913#c7115
----------------------------------------------------------------------
In the Mar 13, 2025 teleconference the following wording was agreed, but the bug
is being left open for now for feedback.
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>[<i>n</i>]<&word</pre>and:<pre>[<i>n</i>]>&word</pre>shall
duplicate one input file descriptor or output file descriptor, respectively,
from another, or shall close one. If <i>word</i> evaluates to one or more
digits, 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 Section 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
<i>exec</i> 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>
Since it was mentioned earlier: what is the intended behaviour of
echo hello | { cat 0<&0 & wait; }
? IMHO, "This initial assignment shall be overridden by any explicit
redirection of standard input within the AND-OR list" was previously
clear that this should print 'hello'. Multiple shells print nothing, but
personally I considered that just shell bugs. However, even under the
old wording we already have one shell implementer using the logic that
0<&0 is a no-op and therefore the implicit </dev/null of background
commands is meant to apply, and under the proposed new wording, I think
that would be the only valid interpretation.
Should this be required to print "hello", to print nothing, or be left
unspecified?
Cheers,
Harald van Dijk
