Chet Ramey wrote, on 20 Mar 2025:
>
> On 3/20/25 12:51 PM, Geoff Clare via austin-group-l at The Open Group wrote:
> > 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.
>
> Sorry, I meant they were aware of the 0<&0 issue and whether it counts as
> an explicit redirection.
I agree the question of whether <&0 counts as a redirection that
overrides the /dev/null assignment must have come up, but that doesn't
necessarily mean it was treated as an "issue". (To me, for something
to qualify as an "issue" it needs to identify a problem that needs
fixing, but maybe that's just me being overly picky.) My guess is
that someone asked that question, someone else answered it by showing
how ksh88 handled the code in the rationale, and then a collective
decision was made that this was worth including in the rationale.
I don't think they gave it much thought, because the reason they put
in the rationale doesn't actually make any sense. It gives the
reason as "the connection of the input to the equivalent of /dev/null
is considered to occur before redirections". No reasoning based on
the order things happen can possibly be right, because the ordering
is the same for the redirection in "cat < file &" (which is required
to override) and the one in "cat <&0 &" (which they said doesn't
override). The real reason is that the redirection <&0 does nothing
(in ksh88). Although, I suppose they could have been taking
"<&0 is a no-op" as read, and treating the "exec < /etc/passwd" as the
redirection in question.
> They simply used a different example than
>
> echo hello | { cat <&0 & wait; }
>
> which should have the same order of operations as the one in the rationale,
> at least from the perspective of the `cat' subshell, but produces different
> output.
It produces different output in practice, but if the 1992 standard had
specified that <&0 is a no-op, it would have required both commands to
produce no output.
> > > 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.
>
> So "yes", then.
Sorry, I'm not sure what "yes" means here. My original question was
an "or": do you think the standard should allow the bash behaviour or
will you change bash to behave like other shells?
> But then how about my example from above, where the only
> change is that the shell is the parent of both processes? How do you
> differentiate between the two from the process forked to run `cat <&0'?
Let me turn that around: how does bash differentiate between the two?
(and likewise for the other shells where they produce different output).
Once we know what criteria shells base it on, we can think about how
to specify it as a condition in the standard.
--
Geoff Clare <[email protected]>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
