|Do you know where your variables are?|
Precedence/Prototypes - Re^2: Detecting when a child process is killed unexpectedlyby jakobi (Pilgrim)
|on Oct 17, 2009 at 10:05 UTC||Need Help??|
> 1) A faulty assumption that the process exit code covers the 'death by signal' case.
SIGSTOP e.g. is indeed something to skip later-on in detecting when to terminate.
But there's still an issue: ignored child state changes must be either ignored in the reaper or in the loop exit condition, otherwise we exit the loop on e.g. SIGSTOP as well.
> 2) Missing parentheses on the exists statements, giving the wrong precedence.
Here I got curious, as the test script behaved as expected when I killed my sleep child processes with zap sleep.3.
While 'and' surely makes the condition more readable, it doesn't look like '&&' leads to an unintended precedence. Which you'd normally expect with '&&' (when using it yourself intentionally). Why this? ->
(I'd naively expected Deparse to be a bit more explicit in its rephrasing. Anyway:)
After reading man perlop, exists() is a named unary operator, and thus has precedence over both '&&' and 'and'. The function f in contrast is a 'list operator (rightward)', with a precedence lower than '&&'.
So the precedence in the statement was correct. And considering the three of us, this loop exit statement is well on it's way to become a future maintenance trap :).
Suggestion: Consider replacing '&&' with the more normal/readable 'and'.
Note that using parens is still required to protect against e.g. prototypes overturning naive precedence expectations wrt e.g. comparison operators:
f 3 >= 5
/me leaves to fetch an Arkansas stone and some honing oil in order to remove the embarassing nicks out of /my paranoia.