in reply to how to stop command

Note that the pattern eval { ... }; if ($@) { ... } suffers from issues, and this pattern is better: eval { ...; 1 } or { ... }; - or just use a module like Try::Tiny.

Other than the scoping issue of @file_list that hippo pointed out, I'm not sure I understand what problems you're having. I tried the following code on Linux and it times out the ls just fine:

use warnings; use strict; use Data::Dumper; my @file_list; eval { local $SIG{ALRM} = sub { die "alarm\n" }; alarm 5; chomp( @file_list = `sleep 10; ls /tmp` ); die "ls: \$?=$?" if $?; alarm 0; 1 } or do { die $@ unless $@ eq "alarm\n"; warn "Timed out"; }; print Dumper(\@file_list);

Also, have a look at IPC::Run, it has timeout support, and support for several more powerful features. Here's an example that also shows Try::Tiny:

use warnings; use strict; use Data::Dumper; use IPC::Run qw/ run timeout /; use Try::Tiny; my @file_list; try { run ['ls','/tmp'], \undef, \my $lines, timeout(5) or die "ls: \$?=$?"; @file_list = split /\n/, $lines; } catch { die $_ unless /^IPC::Run: timeout/; warn "Timed out"; }; print Dumper(\@file_list);

Replies are listed 'Best First'.
Re^2: how to stop command
by tobyink (Canon) on Jul 23, 2018 at 04:26 UTC

    I don't think this particular eval is likely to suffer from the issues you mentioned. There's no OO code inside the eval, so no object can be destroyed inside the eval.

      I don't think this particular eval is likely to suffer from the issues you mentioned.

      True, in this case it's probably fine. But I think it's still a good habit to get into - even seemingly innocent pieces of code can trigger the problematic behavior:

      eval { $foo = `some_bad_command` or die "blam" }; warn $@ if $@;

      won't print anything if $foo happened to be an object with the problematic DESTROY on a problematic version of Perl.

A reply falls below the community's threshold of quality. You may see it by logging in.