Redirecting to `stdin`: who outputs the contents afterwards?

Question

Consider the following example in Bash shell

$ echo 'test' | wc -c
5

Everything works as expected. Now let's change it to

$ echo 'test' >&0 | wc -c
test
0

Now, that 0 in the output makes prefect sense: echo has sent everything to stdin (which is traditionally writable) and nothing to stdout, so nothing gets piped over to wc. But how did the output appear in the console? Who printed that test line and when?

And finally, the third test (for platforms that support stdbuf)

$ stdbuf -i0 -o0 -e0 echo 'test' >&0 | wc -c
0
test

What happened here? Why did the order change?

Answer 1

The stdin of echo is connected to the terminal, so that's where the output goes when you do echo 'test' >&0. Usually, echo doesn't use its stdin, but it is there, the same way it is for e.g. cat. On the other hand, if you run echo foo | echo test >&0, you get an error for "Bad file descriptor", since the pipe connected to the stdin of the second echo is read-only for it.

In your other snippet, with stdbuf, I think what happens is that it's a race between wc noticing the pipe in its stdin is closed (you redirected the write side away, so there's no-one writing to the pipe), and echo writing to the terminal. It's not about the buffering (which really shouldn't matter since echo has to flush the buffer when finishing anyway), you can get the same with strace echo ... or env echo .... Anything on the left side that makes launching echo slower should have an effect. Also, remember that with just echo | wc, you're likely to run the shell's built-in implementation of echo, and with stdbuf, env or strace, an external echo runs. Builtins are faster.

In general, if you have two processes writing somewhere simultaneously, you can't make any assumptions about the order of the writes, unless they explicitly syncronize.