Following the eval we are check $@ to verify the eval was successful.

There was/is a bug in eval that means the eval { ... }; if ($@) { ... } pattern is not reliable (even though it still appears in examples all over the web). It's much better to do eval { ...; 1 } or do { ... };, or use a module like Try::Tiny.

We are building the put command on the fly and then executing 'eval $PutCMD'.

I don't quite understand why you're doing it this way - you might get bitten by quoting/escaping issues. Note that you can always just pass an array of arguments to a method, and build that array dynamically. This example should do the same as the command you showed:

my @args = ("$opt_local_dir/$do_file");
push @args, $remote_file, copy_perms => 0;
push @args, copy_time => 0;
eval { $ftp->put(@args); 1 }
    or warn "put failed: ".($@//"unknown error");
[download]

Note that's eval BLOCK, not eval STRING, which means the code contained in the BLOCK is compiled and checked for syntax errors along with the surrounding code, and at runtime just functions as an error catching mechanism.

Following the eval we are check $@ to verify the eval was successful.

See full, enlightening discussion at The 'eval "require $module; 1"' idiom

perl normally wouldn't display runtime errors if a subroutine doesn't do what it is supposed to do.

eval won't either.

If the routines you are running return a status, then you want to catch that status coming back from eval:

my $status = eval "3+4";
[download]

$status should be '7'. Only if the code you are executing "dies" or throws a warning, in the perl sense, would eval return something in $@.

Does that help?

Only if the code you are executing "dies" or throws a warning, in the perl sense, would eval return something in $@.

But as I wrote, there are cases where the code in the eval can die, and $@ doesn't get set (Update: or to be more specific, gets clobbered so that it's no longer available after the eval). A simple demo of this bug:

use warnings;
use strict;

sub Foo::DESTROY { eval {} }

eval {
    for (bless {}, "Foo") {
        print "Hello";
        die "KABOOM";
    }
};
print "<$@>\n";  # Where's the kaboom? There was supposed
                 # to be an earth-shattering kaboom!
[download]

Even on Perl 5.26, this only prints "Hello<>". That's why the eval { ...; 1 } or do { ... }; pattern is better - choroba showed how that pattern still works even in the presence of a similar bug on Perls <5.14 here.

If the routines you are running return a status, then you want to catch that status coming back from eval

I would suggest writing it this way, where of course 3+4 is a stand-in for something more complex (and it may also be a false value):

my $status;
eval '$status = 3+4; 1' or warn $@||"unknown error";
[download]