On 18/03/2025 17:46, Geoff Clare via austin-group-l at The Open Group wrote:
Harald van Dijk wrote, on 18 Mar 2025:
On 18/03/2025 14:45, Geoff Clare via austin-group-l at The Open Group wrote:
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.
Huh, so they do.
bosh also does the same.
If bash, ksh, bosh all do the same thing, but POSIX specifies another thing,
is there a rationale somewhere explaining why?
I can't think of any reason they would deliberately behave that way, so
unless one of the shell authors can come up with some justification, I'm
going to consider it a bug.
It turns out it was clear from the bash source code: a pipe also counts
as a redirection of stdin, therefore this is treated the same as the
below. And likely the same applies to ksh and bosh.
But still, in bash, 0<&0 really does have this effect. Here is a better test
case:
$ bash -o posix -c 'cat & wait'
<immediately exits>
$ bash -o posix -c 'cat 0<&0 & wait'
<waits for stdin>
Okay, looks like we'll need Chet's input on this part.
And it looks like bash is not alone in that either, in bosh and ksh 0<&0
actually does also have this effect, but only if it is specified outside
of the backgrounded command:
$ echo hello | ksh -o posix -c '{ cat & wait; }'
$ echo hello | ksh -o posix -c '{ cat & wait; } 0<&0'
hello
Same with bosh.
Cheers,
Harald van Dijk
