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.
The following doesn't print anything until Perl v5.26.0.
use strict; sub Foo::DESTROY { eval { 1 } } my $foo = bless {}, 'Foo'; eval { $foo = `some_bad_command` or die "blam" }; warn $@ if $@;
(Interestingly, according to a bisect, the commit that changed this behavior is a0833292cf, which has nothing to do with fixing $@ issues, so it appears to just be a side effect.)
In reply to Re^3: how to stop command
by haukex
in thread how to stop command
by dideod.yang
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |