On 3/20/25 7:04 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Chet Ramey wrote, on 18 Mar 2025:On 3/18/25 1:46 PM, 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.Oh, stop. If this behavior predates the standard, and is present in the two baseline shells the standard used, it's a deviation from existing practice by POSIX and should have been noted. Otherwise, it's little more than "you're not conformant with this requirement we invented." Which is fine, not the first time, but at least be forthright about it.This issue has only just been raised with the POSIX developers, so unless you expect them to be capable of time travel, you can't expect it to have been noted in the standard.
I don't buy that. The example Lawrence found in the rationale has been there since at least 1992. The standard developers were certainly aware of the issue, even if they did not use the exact example we're using here. Maybe something more than an example in the rationale would have been useful. Anyway, the real question is whether or not a pipe counts as an explicit redirection for this purpose.
In another email you referred to: https://lists.gnu.org/archive/html/bug-bash/2016-01/msg00062.html as the reason bash now behaves this way. In your first response in that thread you pointed out that POSIX requires the old bash behaviour.
Yeah, I originally thought that.
Later someone suggested that the pipe counts as an explicit redirection, and you correctly replied that it doesn't count. Later discussion by others about pipe redirection needing to be "taken as read" missed animportant point.
Then I started looking at what other shells did. Since both the SVR4 sh and ksh (93 at the time, but I assumed 88 did the same thing, which it does), I figured compatibility with the base implementations was important, and, frankly, that behavior is more useful. I also figured that when POSIX deliberately deviated from the base implementations, it said why. Since there isn't an explanation here, chances are good that it was a bug in the standard. The POSIX wording at the time was:
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.
Sure. The question is as I put it above.
Note that it said the assignment to /dev/null happens *before* any explicit redirections are performed. Since setting up the pipe happens before the asynchronous list is executed, it can't count as an explicit redirection that is done after the assignment to /dev/null.
OK. Then this is something that could have been considered in the rationale, since it's the exact opposite of what existing contemporary implementations did.
It's a shame that nobody who participated in that discussion thought to raise the issue with the Austin Group; it could have been addressed in POSIX.1-2024.
Maybe, maybe not. I was occupied elsewhere.
(Someone should check ksh88 and verify or disprove my assumption that ksh88 behaved the same as ksh93. I don't have easy access to a Solaris vm right now.)$ /usr/xpg4/bin/sh -c 'set +m; echo hello | { cat & wait; }' hello
Thanks.
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.I gave it: until just now, 0<&0 was unspecified and considered an `explicit' redirection that overrode the implicit redirection from /dev/null. The original language, from 1992, is "In all cases, explicit redirection of standard input shall override this activity." Bash interpreted that to mean that the implicit redirection of didn't happen.The input we need from you on 0<&0 is, given that bash's behaviour differs from the other shells whose behaviour we normally take into consideration, do you think the resolution of bug 1913 should allow the current bash behaviour or will you change bash to behave like those other shells?
I'll have to look at it after bash-5.3 is released. To be clear, this means
that the implicit redirection from /dev/null takes place before any
redirections are processed, right? And a secondary question is whether or
not a pipe counts as an explicit redirection.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
