system not returning correct return code.

Discussion in 'Perl Misc' started by omi, Mar 3, 2009.

  1. omi

    omi Guest

    Please see following snip of the code:

    $SIG{CHLD} = 'IGNORE';

    my $ret1 = `ls jjsjds`;
    my $ret = $?;


    If we see the value of return code, that is not correctly set.
    and this problem is coming because of the "$SIG{CHLD} = 'IGNORE';"
    flag is set.
    we if remove that everything is working fine, but that is requirement
    of the code, since we are using this code with perl socket server
    code, which should not have to create "defunct" processes.

    Please suggest solution on this, where both setting a flag and getting
    output with system can hold in the code.

    Thanks,
    OMkar
     
    omi, Mar 3, 2009
    #1
    1. Advertising

  2. omi

    omi Guest

    Re: system not returning correct return code.

    On Mar 3, 9:14 pm, omi <> wrote:
    > Please see following snip of the code:
    >
    > $SIG{CHLD} = 'IGNORE';
    >
    > my $ret1 = `ls jjsjds`;
    > my $ret = $?;
    >
    > If we see the value of return code, that is not correctly set.
    > and this problem is coming because of the "$SIG{CHLD} = 'IGNORE';"
    > flag is set.
    > we if remove that everything is working fine, but that is requirement
    > of the code, since we are using this code with perl socket server
    > code, which should not have to create "defunct" processes.
    >
    > Please suggest solution on this, where both setting a flag and getting
    > output with system can hold in the code.
    >
    > Thanks,
    > OMkar


    Moreover this code perfectly work, if server [which includes this
    snip] is running on the Windows BOX.
     
    omi, Mar 3, 2009
    #2
    1. Advertising

  3. Re: system not returning correct return code.

    omi wrote:
    > On Mar 3, 9:14 pm, omi <> wrote:
    >> Please see following snip of the code:
    >>
    >> $SIG{CHLD} = 'IGNORE';
    >>
    >> my $ret1 = `ls jjsjds`;
    >> my $ret = $?;
    >>
    >> If we see the value of return code, that is not correctly set.
    >> and this problem is coming because of the "$SIG{CHLD} = 'IGNORE';"
    >> flag is set.
    >> we if remove that everything is working fine, but that is requirement
    >> of the code, since we are using this code with perl socket server
    >> code, which should not have to create "defunct" processes.
    >>
    >> Please suggest solution on this, where both setting a flag and getting
    >> output with system can hold in the code.
    >>
    >> Thanks,
    >> OMkar

    >
    > Moreover this code perfectly work, if server [which includes this
    > snip] is running on the Windows BOX.


    perldoc perlipc:

    "On most Unix platforms, the CHLD (sometimes also known as CLD) signal
    has special behavior with respect to a value of 'IGNORE'. ... Calling
    wait() with $SIG{CHLD} set to 'IGNORE' usually returns -1 on such
    platforms."


    perldoc perlvar

    "$? ... is just the 16-bit status word returned by the wait() system call"


    Since SIGCHLD is "Notification to parent on child stop or exit" I'm not
    entirely surprised that ignoring it leads to the parent not knowing the
    child's exit code.

    Does SIGCHLD mean anything on Windows? Presumably the mechanism for
    communicating exit codes might differ?

    --
    RGB
     
    RedGrittyBrick, Mar 3, 2009
    #3
  4. Re: system not returning correct return code.

    On 2009-03-03, Ben Morrow <> wrote:
    >
    > Quoth omi <>:
    >> On Mar 3, 9:14 pm, omi <> wrote:
    >> > Please see following snip of the code:
    >> >
    >> > $SIG{CHLD} = 'IGNORE';
    >> >
    >> > my $ret1 = `ls jjsjds`;
    >> > my $ret = $?;
    >> >
    >> > If we see the value of return code, that is not correctly set.
    >> > and this problem is coming because of the "$SIG{CHLD} = 'IGNORE';"
    >> > flag is set.

    >
    > Yes. From the $? entry in perldoc perlvar:
    >
    > If you have installed a signal handler for "SIGCHLD", the value
    > of $? will usually be wrong outside that handler.
    >
    > On systems that honour "IGNORE" for SIGCHLD, it counts as a signal
    > handler. So don't do that.


    I would like that quote to be verified. Look, right now I have a big
    deal of coding (testing mostly) about childs, pipes, etc. While
    experimenting I've set C<$SIG{CHLD} = sub { warn $? }>. And I was
    surprised to see C<0> as the inside value. I<$?> is set, and has proper
    value, but only after B<waitpid>. Wouldn't like some kind perlist with
    deeper insight comment on this?

    *CUT*

    --
    Torvalds' goal for Linux is very simple: World Domination
    Stallman's goal for GNU is even simpler: Freedom
     
    Eric Pozharski, Mar 3, 2009
    #4
  5. omi wrote:
    > Please see following snip of the code:
    >
    > $SIG{CHLD} = 'IGNORE';
    >
    > my $ret1 = `ls jjsjds`;
    > my $ret = $?;
    >
    >
    > If we see the value of return code, that is not correctly set.
    > and this problem is coming because of the "$SIG{CHLD} = 'IGNORE';"
    > flag is set.
    > we if remove that everything is working fine, but that is requirement
    > of the code, since we are using this code with perl socket server
    > code, which should not have to create "defunct" processes.
    >
    > Please suggest solution on this, where both setting a flag and getting
    > output with system can hold in the code.


    I'd probably make it double fork when it does the (non-backtick) forks,
    so zombies are cleaned up by the OS.

    Or you could put a { local $SIG{CHLD}; .... } around the backticks, then
    use waitpid with the no wait option to clean up anything that exited in
    the mean time.

    Xho
     
    Xho Jingleheimerschmidt, Mar 4, 2009
    #5
  6. Re: system not returning correct return code.

    Eric Pozharski wrote:
    > On 2009-03-03, Ben Morrow <> wrote:
    >> Quoth omi <>:
    >>> On Mar 3, 9:14 pm, omi <> wrote:
    >>>> Please see following snip of the code:
    >>>>
    >>>> $SIG{CHLD} = 'IGNORE';
    >>>>
    >>>> my $ret1 = `ls jjsjds`;
    >>>> my $ret = $?;
    >>>>
    >>>> If we see the value of return code, that is not correctly set.
    >>>> and this problem is coming because of the "$SIG{CHLD} = 'IGNORE';"
    >>>> flag is set.

    >> Yes. From the $? entry in perldoc perlvar:
    >>
    >> If you have installed a signal handler for "SIGCHLD", the value
    >> of $? will usually be wrong outside that handler.
    >>
    >> On systems that honour "IGNORE" for SIGCHLD, it counts as a signal
    >> handler. So don't do that.

    >
    > I would like that quote to be verified.


    Which aspect?

    > Look, right now I have a big
    > deal of coding (testing mostly) about childs, pipes, etc. While
    > experimenting I've set C<$SIG{CHLD} = sub { warn $? }>. And I was
    > surprised to see C<0> as the inside value. I<$?> is set, and has proper
    > value, but only after B<waitpid>. Wouldn't like some kind perlist with
    > deeper insight comment on this?


    $? is only set after the thing that sets it, yes. Being inside the
    handler doesn't automatically cause $? to get set, it just means that
    the sig handler that you are already in won't get in the way of it being
    set, like it would if a sig handler exists but were you not in the sig
    handler. (Which is not to say that other things couldn't get in the way
    of $? being set correctly when inside a sig handler, just not the sig
    handle itself.)


    Xho
     
    Xho Jingleheimerschmidt, Mar 4, 2009
    #6
  7. Re: system not returning correct return code.

    On 2009-03-04, Xho Jingleheimerschmidt <> wrote:
    > Eric Pozharski wrote:
    >> On 2009-03-03, Ben Morrow <> wrote:
    >>> Quoth omi <>:
    >>>> On Mar 3, 9:14 pm, omi <> wrote:
    >>>>> Please see following snip of the code:
    >>>>>
    >>>>> $SIG{CHLD} = 'IGNORE';
    >>>>>
    >>>>> my $ret1 = `ls jjsjds`;
    >>>>> my $ret = $?;
    >>>>>
    >>>>> If we see the value of return code, that is not correctly set.
    >>>>> and this problem is coming because of the "$SIG{CHLD} = 'IGNORE';"
    >>>>> flag is set.
    >>> Yes. From the $? entry in perldoc perlvar:
    >>>
    >>> If you have installed a signal handler for "SIGCHLD", the value
    >>> of $? will usually be wrong outside that handler.
    >>>
    >>> On systems that honour "IGNORE" for SIGCHLD, it counts as a signal
    >>> handler. So don't do that.

    >>
    >> I would like that quote to be verified.

    >
    > Which aspect?


    "If you have ... that handler."

    >> Look, right now I have a big
    >> deal of coding (testing mostly) about childs, pipes, etc. While
    >> experimenting I've set C<$SIG{CHLD} = sub { warn $? }>. And I was
    >> surprised to see C<0> as the inside value. I<$?> is set, and has proper
    >> value, but only after B<waitpid>. Wouldn't like some kind perlist with
    >> deeper insight comment on this?

    >
    > $? is only set after the thing that sets it, yes. Being inside the
    > handler doesn't automatically cause $? to get set, it just means that
    > the sig handler that you are already in won't get in the way of it being
    > set, like it would if a sig handler exists but were you not in the sig
    > handler. (Which is not to say that other things couldn't get in the way
    > of $? being set correctly when inside a sig handler, just not the sig
    > handle itself.)


    (that seems my english is a way bad still) Did I got that right? The
    perldoc wants to say that even if I'm in B<waitpid> and I get SIGCHLD
    then the I<$?> still would be unset?

    p.s. Look, I can experimentally get what's going on, I just want to get
    what perldoc wants to say.

    --
    Torvalds' goal for Linux is very simple: World Domination
    Stallman's goal for GNU is even simpler: Freedom
     
    Eric Pozharski, Mar 5, 2009
    #7
  8. Re: system not returning correct return code.

    On 2009-03-05, Ben Morrow <> wrote:
    >
    > Quoth Eric Pozharski <>:
    >> On 2009-03-04, Xho Jingleheimerschmidt <> wrote:
    >> > Eric Pozharski wrote:
    >> >> On 2009-03-03, Ben Morrow <> wrote:
    >> >>>
    >> >>> Yes. From the $? entry in perldoc perlvar:
    >> >>>
    >> >>> If you have installed a signal handler for "SIGCHLD", the value
    >> >>> of $? will usually be wrong outside that handler.
    >> >>>
    >> >>> On systems that honour "IGNORE" for SIGCHLD, it counts as a signal
    >> >>> handler. So don't do that.

    *SKIP*
    >>
    >> (that seems my english is a way bad still) Did I got that right? The
    >> perldoc wants to say that even if I'm in B<waitpid> and I get SIGCHLD
    >> then the I<$?> still would be unset?

    >
    > No. What the perldoc is saying is
    >
    > If you have a SIGCHLD handler, then any code *outside* that handler
    > will not see the correct value for $?.
    >
    > That is:
    >
    > #!/usr/bin/perl
    >
    > # $? is useless here.
    >
    > $SIG{CHLD} = sub {
    >
    > # $? is still useless here, because nothing inside this handler
    > # has set it yet.
    >
    > waitpid ...; # or something else that sets $?
    >
    > # $? has the correct value here.
    > };
    >
    > # $? is useless again here.
    >
    > One consequence of this is that if you have $SIG{CHLD} = "IGNORE", $? is
    > *never* useful, since there is none of your code running inside the
    > handler.


    Thanks, I see the light now.


    --
    Torvalds' goal for Linux is very simple: World Domination
    Stallman's goal for GNU is even simpler: Freedom
     
    Eric Pozharski, Mar 6, 2009
    #8
  9. omi

    omi Guest

    Re: system not returning correct return code.

    On Mar 6, 7:49 am, Eric Pozharski <> wrote:
    > On 2009-03-05, Ben Morrow <> wrote:
    >
    >
    >
    >
    >
    > > Quoth Eric Pozharski <>:
    > >> On 2009-03-04, Xho Jingleheimerschmidt <> wrote:
    > >> > Eric Pozharski wrote:
    > >> >> On 2009-03-03, Ben Morrow <> wrote:

    >
    > >> >>> Yes. From the $? entry in perldoc perlvar:

    >
    > >> >>>    If you have installed a signal handler for "SIGCHLD", the value
    > >> >>>    of $? will usually be wrong outside that handler.

    >
    > >> >>> On systems that honour "IGNORE" for SIGCHLD, it counts as a signal
    > >> >>> handler. So don't do that.

    > *SKIP*
    >
    > >> (that seems my english is a way bad still) Did I got that right?  The
    > >> perldoc wants to say that even if I'm in B<waitpid> and I get SIGCHLD
    > >> then the I<$?> still would be unset?

    >
    > > No. What the perldoc is saying is

    >
    > >     If you have a SIGCHLD handler, then any code *outside* that handler
    > >     will not see the correct value for $?.

    >
    > > That is:

    >
    > >     #!/usr/bin/perl

    >
    > >     # $? is useless here.

    >
    > >     $SIG{CHLD} = sub {

    >
    > >         # $? is still useless here, because nothing inside thishandler
    > >         # has set it yet.

    >
    > >         waitpid ...;    # or something else that sets $?

    >
    > >         # $? has the correct value here.
    > >     };

    >
    > >     # $? is useless again here.

    >
    > > One consequence of this is that if you have $SIG{CHLD} = "IGNORE", $?is
    > > *never* useful, since there is none of your code running inside the
    > > handler.

    >
    > Thanks, I see the light now.
    >
    > --
    > Torvalds' goal for Linux is very simple: World Domination
    > Stallman's goal for GNU is even simpler: Freedom


    For time being, Finally I remove the dependency of the dependency of
    the Flag SIGCHILD to be set ;)
     
    omi, Mar 7, 2009
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dan

    correct or not correct?

    Dan, Oct 2, 2003, in forum: HTML
    Replies:
    7
    Views:
    448
  2. Nathan Sokalski
    Replies:
    2
    Views:
    1,134
  3. Nathan Sokalski
    Replies:
    2
    Views:
    1,598
    Nathan Sokalski
    Aug 9, 2008
  4. J.Ram
    Replies:
    7
    Views:
    655
  5. Nathan Sokalski
    Replies:
    2
    Views:
    1,328
    Nathan Sokalski
    Aug 9, 2008
Loading...

Share This Page