Chet Ramey wrote, on 20 Mar 2025:
>
> 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:
> > > > 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.
How does that example show that they were aware of any of the recently
raised issues in this area?
All it says is that:
exec < /etc/passwd
cat <&0 &
wait
produces no output, and that's true for ksh88, which is presumably
what they tested it with at the time.
Obviously they must have been unaware, when they wrote that example, that
the normative text does not specify the behaviour of <&0, otherwise they
would have changed the normative text.
> > > > > 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.
The difference is specifically for the commands at the top of this last
quote, or the following variant which doesn't need you to observe that
cat is waiting for input:
$ echo hello | /usr/xpg4/bin/sh -c 'cat 0<&0 & wait'
$ echo hello | ksh93u+m -o posix -c 'cat 0<&0 & wait'
$ echo hello | mksh -c 'cat 0<&0 & wait'
$ echo hello | dash -c 'cat 0<&0 & wait'
$ echo hello | bash -o posix -c 'cat 0<&0 & wait'
hello
which, coincidentally, is pretty much the same situation as the example
in the rationale.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
