in reply to Re: END{} Subroutine not being called for Child process
in thread END{} Subroutine not being called for Child process

Appreciate the info on the SIGTERM trapping, that looks like it's my problem. I wasn't aware that sending a kill signal just blew the program out of the water; I think that comes from never having had to code in this context before.

I've been considering moving STD outputs to files instead of to /dev/null, although at this point, I've coded around much of what's there, so I'm not sure how much more benefit I would gain. I do switch back and forth between having those lines commented out and not; the line you were referring to in the programExit() subroutine was intended to see if I was hitting the END{} sub, and STDOUT was open when I was using it.

I assume the code you're referring to in the last paragraph is this one:

if(!($pid = fork)){ system("$parser $script"); }

I'm confused as to what you're saying, though. When I fork the process, I believed that the process in question would only run what was inside the bracket, then exit. Is that not the case? Should I be using exec(), in that case?

Replies are listed 'Best First'.
Re^3: END{} Subroutine not being called for Child process
by ikegami (Patriarch) on Aug 04, 2009 at 19:37 UTC

    When I fork the process, I believed that the process in question would only run what was inside the bracket, then exit.

    if doesn't do anything special if the condition happens to be a call to fork. It won't exit if you don't tell it to exit. Indeed, it sounds like you want exec instead of system.

      Thanks for the clarification. I've made that change, and everything seems to be working fine. I appreciate your help.
Re^3: END{} Subroutine not being called for Child process
by ig (Vicar) on Aug 04, 2009 at 20:37 UTC

    In general I don't redirect STDOUT or STDERR to /dev/null and never when I am debugging. Very often, when something unexpected goes wrong, important clues are written to one of these outputs. This may include output from modules that have been used, which might not be obvious without reading all the module source.

      Point well taken. I can see the benefits of not redirecting those outputs, especially during a debugging process. From a long term solution, I think this is the right answer for the script as written, however. If I were to rewrite it, I might rewrite it to simply open those outputs to files instead, but the handling code is already written (and readable, and functional), so I don't see a lot of value in re-factoring that part of the code right now.