On 3/21/25 5:52 AM, Geoff Clare via austin-group-l at The Open Group wrote:
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 needsfixing, but maybe that's just me being overly picky.)
My definition, which is of course informal, is that an issue is something worth consiering or that was considered. It doesn't need to be a problem, per se, just a discussion point.
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.
OK. Even though the SVR4 shell behaved differently, I guess that was enough to get through it and move on.
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).
So presumably an implementation artifact.
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.
OK, so it's still unspecified at that time.
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.
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.
bash, ksh93/ksh88, and the SVR4 sh all behave the same here. Other shells
output nothing. I have no idea what the ksh and the SVR4 sh code looks like
that makes them decide as they do. Adding an explicit `0<&0' to the cat
command doesn't make a difference; that's a different issue.
When bash's own standard input is a pipe, it doesn't bother with this
analysis. It doesn't bother with it unless it executes the pipeline itself.
--
``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
