in reply to Different values when using $? to detect seg faults

Is there simply something wrong in my code?
I think so. This line is subtly wrong: my $execTwo = "$command &> log ";You're not just re-directing there, you're also starting the command in the background. To redirect both stderr and stdout you'd need >&, not &>. So you're getting the return value of the shell, not your program.

<waffle>I may be mis-reading your code, but I think that's what's happening.</waffle>

Replies are listed 'Best First'.
Re^2: Different values when using $? to detect seg faults
by graff (Chancellor) on Mar 08, 2005 at 04:11 UTC
    This line is subtly wrong:
    my $execTwo = "$command &> log ";

    Well, that might depend on what type of shell we're talking about. In bash, the ampersand followed immediately by ">" is the "preferred" way to redirect both stdout and stderr to the named output file, while in a C-shell, you have to use the angle-bracket followed by the ampersand (and bash also supports this order -- who knows why bash doesn't "prefer" it...)

    Anyway, another confounding factor is that the shell invoked by perl's "system()" call might not be the same as the user's login shell, so things that the user can do on the command line might not work in the system() call.

    So, the idea that the command is being backgrounded as well as having stdout redirected is certainly plausible, maybe even likely; but it's also quite understandable that the OP thought he was doing things the right way. The point is: be very careful about system calls that use shell-dependent syntax, and avoid such things as much as possible.

Re^2: Different values when using $? to detect seg faults
by jpeg (Chaplain) on Mar 08, 2005 at 01:37 UTC
    That's correct. '&' invokes a subshell and *always* returns 0. It can't get the return value of the subshell or the shell's command because it doesn't wait for the subshell to finish.
    --
    jpg