Harald van Dijk wrote, on 13 Mar 2025: > > > ---------------------------------------------------------------------- > > (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'.
I disagree - as per my earlier email, quoted at the end of the bug description, the standard says "one input file descriptor from another", implying that they are two different file descriptors, so the behaviour of 0<&0 is currently unspecified (implicitly). What I, and I assume most application writers, would expect to happen in practice is that 0<&0 redirects standard input to come from the place that standard input already comes from. In the situation where standard input is "assigned to an open file description that behaves as if /dev/null had been opened for reading only" I would expect standard input to continue to behave like /dev/null after the redirection. The "overridden by any explicit redirection" text doesn't have any effect because the explicit redirection is not specifying somewhere new for standard input to be redirected from. > 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? I think it should be (and will be with the proposed new wording) required to print nothing. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
