Re: $SIG{INT} unlink problem

I have little actual experience with signal handlers, but as I understand you should do as little as possible in them and certainly avoid calling anything that might not be reentrant. The following may or may not work better than your current solution. YMMV.

my $is_break = 0;
$SIG{INT} = sub { $is_break = 1 };
my $result = is_success( getstore( $uri, $localfile ) );
if($is_break) {
    print STDERR 'Removing incomplete download...';
    -f $localfile and (
        unlink $localfile
        or print STDERR "\rCouldn't remove incompletely downloaded $lo
+calfile: $!\n"
    );
}
exit $result;
[download]

Update: added file check as per sauoq's post.

Makeshifts last the longest.

Comment on Re: $SIG{INT} unlink problem Download Code

Replies are listed 'Best First'.
Re: Re: $SIG{INT} unlink problem by sauoq (Abbot) on Aug 21, 2002 at 01:11 UTC
I agree entirely with Aristotles suggestion. Additionally, you should probably just check to see if the file exists before trying to remove it. That should take care of your error. -sauoq "My two cents aren't worth a dime.";	[reply]
Re: Re: $SIG{INT} unlink problem by Cirollo (Friar) on Aug 22, 2002 at 13:41 UTC
FYI, here is a tidbit on signal handlers, from the 5.8.0 perldelta: Safe Signals Perl used to be fragile in that signals arriving at inopportune moments could corrupt Perl's internal state. Now Perl postpones handling of signals until it's safe (between opcodes). This change may have surprising side effects because signals no longer interrupt Perl instantly. Perl will now first finish whatever it was doing, like finishing an internal operation (like sort()) or an external operation (like an I/O operation), and only then look at any arrived signals (and before starting the next operation). No more corrupt internal state since the current operation is always finished first, but the signal may take more time to get heard. Note that breaking out from potentially blocking operations should still work, though.	[reply]