Confused why script does not exit

Question

I have this script verbatim:

#!/usr/bin/env bash


handle_json(){
  while read line; do
    cat <<EOF
{"@json-stdio":true,"value":{"mark":"$1","v":"$line"}}
EOF
    done;
}

( echo; echo; echo 'du results:'; exit 0 ) > >(handle_json foo);

echo "zoom"

when I execute it, I get this:

I have to manually kill it with ctrl-C since it won't exit on it's own.

All I am trying to do is send the stdout of the subshell to the bash function so it JSON stringify the output (don't worry about escaping special chars for now).

Anybody know why this script doesn't exit on it's own?

UPDATE:

this actually does what I want it to do:

( echo; echo; echo 'du results'; ) |  handle_json 'foo';

echo "zoom"

the above uses the pipe operator instead of redirection/process substition. I never expected the pipe operator to work here. Can someone explain why/how it works?

Answer 1

As far as I can tell, your script did exit; it's just that the process substitution finished running and printing in the background after the outer shell printed its prompt.

A way to avoid this would be to simply pipe into your function instead of using > >(...):

( echo; echo; echo 'du results:'; exit 0 ) | handle_json foo

This works because, when writing cmd1 | cmd2, the two commands are started in parallel, with the standard output of cmd1 connected to the standard input of cmd2, and bash waits for both to have completed to consider the pipeline complete.

In contrast, cmd1 > >(cmd2) does nearly the same, except that bash does not wait for cmd2 to complete before going on with further commands (in this case, printing "zoom" and then exiting, letting the interactive bash print its prompt): if, by chance, cmd2 takes significantly more time to complete than cmd1, then the kind of surprising race condition you observed happens.