With all due respect to your seniority and all the great, informative posts you have contributed long before I was even a gleam in the forum's eye, I believe your analysis of this pipeline and its redirections to be off the mark.

I will be using "the main shell" to refer to the shell tasked with interpreting the ls-grep pipeline.

The grep process will never be a child of the ls process. And, the ls process will never be a child of the grep process. They will be siblings, each a child of the main shell. Further, the order in which they are created does not matter.

For grep to beget ls would require more than a shell rewrite, it would require a grep one too.

Actually, the fork will happen before the i/o redirection, then an exec. If the i/o redirection were done before forking, file descriptor handling would get very very messy, as the parent would have to juggle things around before the fork, and then restore sanity afterwards (assuming the parent has further business to tend to).

As I understand it, the chain of events to realize the ls-grep pipeline is as follows:

The main shell will first create the descriptors that the pipe will use. Then, it will fork twice (creating two subshells). One of the subshells will eventually exec to become ls and the other will eventually exec to become grep.

One subshell will modify stdout to point to the pipe (this subshell will become ls) and the other will modify stdin (for grep). Before exec, these subshells have to process each command's command-line i/o redirections. In the case of the subshell that will become ls, this would make fd 1 a copy of fd 3 and would then close fd 3. In the case of the subshell to become grep, there's nothing to be done but close fd 3. Now, when each subshell exec's, there is no fd 3 available to either process.

Agreed. The same is true of ls.

If I'm the one that's off the mark, I await the Cluestick of Enlightenment

Regards,
Alister