(Historical note: "runhook" was the early name for what would become "plushook".)
runhook's stdin support right now is not great. It reads all of stdin into a variable, which:
options to fix this without changing the current hook paradigm:
If at all possible, tee-juggling is the way I would most want to do this:
Repeat as necessary.
On further inquiry it looks like pipes aren't really great buffering mechanisms (Linux limits them to 64K, up from 4k in 2.6.11).
Really, having hook scripts work as filters is merited from a technical standpoint, as well as being (arguably) merited from a design standpoint.
In short, this is an aspect of pluginhook that ultimately needs to be preserved. Here's the complete rationale for this behavior.
Actually, considering that piped commands run concurrently as well (as they'd have to), and I don't want to force input reading... maybe I just need to suck it up and use tmpfiles (in the multiple-hooks case). Besides, constructing pipes is not something Bash likes to do.
Solution implemented in 9138d27: stdin is passed directly to a hook when there is a single hook script. In the (less common) event there is more than 1 hook, stdin is put into a temp file, which is then directed into each hook in a serial loop.
Being able to have a separate stdin and stdout is massively important, especially for Git hook compatibility. Each hook giving its output as it runs makes total sense, and each hook should run one after another.
Also, since 90% of the time making the temp file and multiplexing is overkill, stdin is now disabled altogether unless the -i flag is passed to runhook.