Chet Ramey wrote, on 24 Mar 2025:
>
> On 3/21/25 5:52 AM, Geoff Clare via austin-group-l at The Open Group wrote:
>
> > > > > 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?
>
> My answer was "I'll have to look at it after bash-5.3 is released." My
> initial impression is that yes, the standard should allow the bash
> behavior to allow piping that it can detect as an explicit redirection,
> but I'm not going to think hard about it until I get bash-5.3 out the door.
>
> Then I asked "To be clear, this means that the implicit redirection from
> /dev/null takes place before any redirections are processed, right?" I'm
> not sure you answered that directly with your response, but I assume the
> answer is "yes," since that's what makes the examples work consistently.
Sorry, but you're mixing up the two different issues we're discussing.
On the "allow piping that it can detect as an explicit redirection" thing,
other shells do the same and I agree the standard should allow it.
The case where bash differs from other shells, as demonstrated above, is
that 0<&0 stops the implicit redirection from /dev/null when bash is
simply executing 'cat 0<&0 & wait' without doing any piping itself.
> > > 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?
>
> OK, let's look at
>
> echo hello | { cat & wait; }
>
> since I think that illustrates the point most clearly.
>
> When bash is the parent of both processes in the pipeline, it knows that
> the standard input to the cat command is a pipe (the group command really
> only affects parsing here, and all the commands in the group command have
> the pipe as their standard input). It treats that pipe as an explicit
> redirection that overrides the usual redirection from /dev/null.
>
> It's the same situation with `( cat & wait )': the parens mostly affect
> parsing and when to fork a subshell, which can be a no-op if you already
> run the right side of the pipeline in a subshell. Bash knows that the input
> to the subshell (and to all of the commands in it) is a pipe, and
> similarly overrides.
Looks like it's not just { ... } and ( ... ), but all compound commands:
$ sh -c 'echo hello | if true; then cat & wait; fi'
hello
$ sh -c 'echo hello | for i in 1; do cat & wait; done'
hello
So let's try and word that in standardese ...
After:
This initial assignment shall be overridden by any explicit
redirection of standard input within the AND-OR list
add:
and may be overridden if the AND-OR list is within a compound
command that follows the control operator '|'
Does that seem okay?
--
Geoff Clare <[email protected]>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
