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.
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.
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 an
important point. 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.
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.
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.
> (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
> > > 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?
--
Geoff Clare <[email protected]>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
