in reply to Re: why does ignoring sigCHLD corrupt return value from system()?
in thread why does ignoring sigCHLD corrupt return value from system()?

By replacing your instruction with system("./prog2.pl") I get a return code of 5 both with and without SIGCHLD ignored.

But what did you get before you made that replacement? I'm guessing -1 in both cases and that your platform just isn't one of the ones that exhibits this.

By the way, why should ignoring SIGCHLD be recommended when using system? Never heard that...

I don't think that such a "recommendation" is suggested by the original post. I doubt he was ignoring SIGCHLD because he was using system(); I'd bet he just ran into this in a program that happened to do both. So, the question is: must we recommend never ignoring SIGCHLD when using system()?

-sauoq
"My two cents aren't worth a dime.";

Replies are listed 'Best First'.
Re: Re: Re: why does ignoring sigCHLD corrupt return value from system()?
by TheHobbit (Pilgrim) on Nov 05, 2003 at 10:14 UTC

    Hi,
    The fact that $SIG{CHLD} is set to wichever value the user chose must not change the behavior of system as stated in perlfunc, expecially where it states that:

    Does exactly the same thing as "exec LIST", except that a fork is done first, and the parent process waits for the child process to complete.

    The parent process needs to intercept SIGCHLD in order to wait(2) for the child process to complete.

    As I stated above, this implies that the value of $SIG{CHLD} must be localized to same value during the execution of system, and so the user value of it outside that execution is (or shuld be) irrelevant.

    Just my 5 (euro) cents.


    Leo TheHobbit
      The fact that $SIG{CHLD} is set to wichever value the user chose must not change the behavior of system as stated in perlfunc

      Agreed. And the OP discusses a case in which it does change the behavior of system. This is a bug.

      The question I posed was whether we should recommend that people avoid ignoring SIGCHLD if they are going to call system. And, I think so. Nevermind how perl should behave. What matters here is how perl does behave. Even if this is fixed in the next release, it is still broken in many current installations.

      -sauoq
      "My two cents aren't worth a dime.";