Harald van Dijk wrote, on 20 Mar 2025:
>
> On 20/03/2025 11:59, Geoff Clare via austin-group-l at The Open Group wrote:
> >
> > I see these as not so much about 0<&0 but the other (asynchronous
> > list) issue. They are special cases of commands where redirections
> > done before an asynchronous list is started affect whether the
> > redirection from /dev/null is done.
>
> Yes, this is based on the "This initial assignment shall be overridden by
> any explicit redirection of standard input within the AND-OR list." See
> below.
>
> > The one with 0<&0 was only
> > previously allowed because 0<&0 had unspecified behaviour;
>
> As Lawrence Velázquez commented elsethread, the rationale includes an
> instance of <&0 that has been there since at least SUSv2 that demonstrates
> that this was always intended to be valid and to leave stdin unchanged, even
> if the normative wording failed to specify this.
Yes, that was a good find by Lawrence. The text dates right back to
POSIX.2-1992 (E.3.9.3.1 on page 843) and it shows that the original
intention was not only that 0<&0 should be a no-op, but also that it
should not override the "connection of the input to the equivalent of
/dev/null".
It's a shame these things weren't made clear in the normative text.
> > cases have never been allowed by POSIX. For example:
> >
> > $ echo hello > FIFO & bash -o posix -c "{ cat & wait; } 0<FIFO"
> > [1] 3690
> > hello
> > $ echo hello > FIFO & ksh93u+m -o posix -c "{ cat & wait; } 0<FIFO"
> > [1] 3699
> > hello
>
> The sentence is ambiguous as to whether "within the AND-OR list" applies to
> "explicit redirection" or to "standard input" and the above shells have
> taken it to apply to "standard input": even though the redirection is
> outside of the AND-OR list, the standard input within the AND-OR list, which
> is the standard input which was inherited from outside the AND-OR list, has
> been explicitly redirected. This is a perfectly valid and sensible
> interpretation, and if the shells have always worked that way, I very much
> expect it was the originally intended interpretation.
I suppose the new Issue 8 text could be read that way. However, the
previous text that was in place from 1992 to 2023 was not ambiguous.
I quoted it in a previous reply to Chet, but here it is again:
If job control is disabled (see set, -m), the standard input for
an asynchronous list, before any explicit redirections are performed,
shall be considered to be assigned to a file that has the same
properties as /dev/null. This shall not happen if job control is
enabled. In all cases, explicit redirection of standard input shall
override this activity.
(The original 1992 text talked about whether the shell is interactive
instead of referring to job control, but the pertinent parts were
identical.)
It says the assignment to /dev/null happens "before any explicit
redirections are performed" and with this context, it is clear that
the later reference to explicit redirection of standard input only
applies to redirections done after the assignment to /dev/null.
Going back to the new Issue 8 text, if you interpret it as applying
to all redirections of standard input, including those not done inside
the AND-OR list, then that interpretation would also require:
echo hello > FIFO & sh -c "exec 0<FIFO; cat & wait"
to write "hello", and no shell I've tested does that.
--
Geoff Clare <[email protected]>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
