I think I’ve figured out how to tweak your experience
to turn it into something other people will be able to reproduce:
$ (echo hello; sleep 1; echo world) | tee >(cat)
hello … and, after a brief delay,
$ echo "$?"
$ (echo hello; sleep 1; echo world) | tee >(echo yo)
$ echo "$?"
As you hopefully understand,
>(command) creates a pipe
to a process running
The standard input of
command is connected to a pathname
that other commands on the command line (in this case,
can open and write to. When
the process sits there and reads from stdin until it gets an EOF.
In this case,
tee has no problem
writing all the data it reads from its stdin to the pipe.
the process writes
yo to the stdout and immediately exits.
This causes a problem for
when it writes to a pipe with no process at the other end,
it gets a SIGPIPE signal.
Apparently OS X’s version of
writes to the file(s) on the command line first, and then its stdout.
So, in your example (
echo hi | tee >(echo yo)),
tee gets the pipe failure on its very first write.
Whereas, the version of
tee on Linux and Cygwin
writes to the stdout first,
so it manages to write
hi to the screen before it dies.
In my enhanced example,
tee dies when it writes
hello to the pipe,
so it doesn’t get a chance to read and write