Pádraig Brady <P@draigBrady.com> writes:
Thanks a lot for the patch.
There is similar functionality in tail.c (which should probably be reused
if we do decide to implement this in tee as it's tricky to do portably).
Anyway the tail(1) case makes sense considering:
Looking at ``check_output_alive'', this logic should be fairly easy to
reuse. Worst case, I'd need to refactor some of the code to handle the
non-pipe-check case more elegantly so that it doesn't become too
unreadable when also adding the logic to pick between poll and select.
tail -f file.log | grep -q trigger && process_immediately
So a similar use case with tee might be:
tee -p <file.in >(grep -q trigger_1) | grep -q trigger_2 &&
process_immediately
However tee wouldn't be waiting for more input in that case.
It would either consume the whole file, or exit when processing it.
So a more appropriate case is:
intermittent_output |
tee -p >(grep -q trigger_1) | grep -q trigger_2 && process_immediately
This case is just about what we were using tee for when I wrote this
patch. We use a compiler wrapper that compares the outputs of few
compilers by running them in parallel (to detect some new behavior), and
we started noticing some builds would mysteriously hang forever. I
traced it back to ``tee'' waiting on stdin even after the child
processes die on occasion.
Really, that was an oversight on my part. I didn't think of the (quite
normal) case of stdin being some long-lived low traffic pipe rather than
either a file or /dev/null or a pipe that gets closed properly after
writing.
Where intermittent_output is stdin, the use case is a bit contrived
as any input will cause tee to exit.
The general more general non stdin case above has some merit,
though not as common as the tail example I think.
Right, but no user input could ever happen when the hangs described
above happened, since it'd happen in some automated code, so (AFAICT)
the only option was to teach tee to detect outputs going away more
promptly.
tee-p-describe.patch