in reply to open-coding a system() operation

I usually use if/elsif/else when forking:

if (my $pid = fork) { # Parent local $SIG{INT} = 'IGNORE'; local $SIG{QUIT} = 'IGNORE'; waitpid($pid, 0); } elsif (defined $pid) { # Child exec 'date'; die 'date not found' } else { die "Can't fork: $!"; }
Which is the same thing, but in my opinion a little easier to read.

Why do you ignore those signals? I know near to nothing about signals and would like to learn (have only used HUP to reload configuration files, and Perl's __DIE__/__WARN__).

Juerd
- http://juerd.nl/
- spamcollector_perlmonks@juerd.nl (do not use).

Replies are listed 'Best First'.
•Re: Re: open-coding a system() operation
by merlyn (Sage) on Apr 22, 2003 at 02:40 UTC
    I ignore the signals because Perl does. Perl emulates the system(3) call from C, which also ignores those signals. That's so you can press ^C while system is running a vi for you, and stop the vi without killing the Perl that is also running.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

Re: Re: open-coding a system() operation
by dug (Chaplain) on Apr 22, 2003 at 04:14 UTC
    I've written this both ways before, but generally prefer the style that merlyn used in the snippet. I like to see potential failures at the beginning of a block of code if it makes sense (it does to me in this snippet). It also fits my brain best to see the child before the parent, since it will most likely be doing the heavy lifting.

    After all this talk of child labor is reminding me of William Blake's "The Chimney Sweeper". Guess I have my night reading lined out for me ;-)

    -- dug