thanx for the heads-up for q1/modulification, Beth :)

For the tcgrep-fork I started to hack on ages ago (who doesn't have a perl grep of his/her own with some special tricks :) ), I indeed recently turned it into a dual nature module. Which I yet have to use as a module... . So I might also find some time to do that for all 5 candidate scripts regardless of cpan or no cpan.

Portability other than Unix-Unix: not quite my cup of tea, with the possible exception of cygwin :>.

As for waitcond, its usable output information is basically just the return code and the fact that it exited: so pipeline in this case includes shell command sequences as well. (cmd1; waitcond...; cmd2)|cmd3. Consider a  ssh HOST make in one shell window, and using waitcond in a different shell for e.g. the tty of the ssh/make command to be idle for more than a few minutes: waitcond not recent tty /dev/pts/13; mpg123 trumpets-of-jericho; echo check for make success or early failure.... (waitcond is the worst of the bunch with its pure process/shell conception)

So let me ask a question 2b:

I've absolutely no naming idea: where in the main module hierarchies e.g. waitcond might fit. Other than maybe not signaling its dual-module/script-nature and just selecting a module hierarchy that at least somewhat matches a not entirely-impossible use case.

Sys::, Proc::, App:: ??? All of which fit (badly/way too generic).

Toplevel (but isn't that even worse)??

???