Harald van Dijk wrote, on 18 Mar 2025:
>
> On 18/03/2025 12:55, Geoff Clare via austin-group-l at The Open Group
> wrote:> 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.
>
> Oh I see, you interpret the & as taking effect first, redirecting stdin as
> if from /dev/null, and then 0<&0 keeping it that way.
Given the full text, I don't see how it can be interpreted any other
way:
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 /dev/null had been opened for reading only.
Note the words "subshell" and "initially".
> But then the "This
> initial assignment shall be overridden by any explicit redirection of
> standard input within the AND-OR list." wording is redundant: if it weren't
> there, that would already be the effect.
Yes it's redundant. If it weren't for the use of "shall", I would
see this part as providing information, not making a requirement.
> The original wording suggested to me that 0<&0 was considered an explicit
> redirection with unspecified/underspecified behaviour, and that like any
> other explicit redirection prevents the implicit 0</dev/null from taking
> place, and then after that, because stdin is still the original stdin, doing
> the sensible thing for that unspecified/underspecified behaviour, 0<&0 would
> continue to use the original stdin.
>
> Notable shells that do it this way are bash and ksh, including in POSIX
> mode, so if a change is made here, that is probably worth calling out
> explicitly.
Those shells also print "hello" without the redirection:
$ sh -c 'set +m; echo hello | { cat & wait; }' # sh here is bash
hello
$ ksh93u+m -c 'set -o posix; set +m; echo hello | { cat & wait; }'
hello
So this has nothing to do with 0<&0 - it's a non-conformance with the
non-job-control asynchronous AND-OR list requirements in some
circumstances.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
