I'd always use a Perl implementation in preference to an external program for two reasons:

1. Portability: the Perl version will probably work anywhere that Perl works. An external program probably won't.
2. Efficiency: opening an external program means that your operating system has to start a new process. Doing the all work inside the original process is more efficient.

There are probably other good reasons, but those two are enough for me.

In my system, there's no /usr/bin/copy so if your release your code, no chance it will work on my system.

File::Copy is part of the standard perl itself, so there's no reason not to use it !

I don't know syslog. I usually use Log::Log4perl . But the idea is the same! Use modules !!

File::Copy is part of the standard perl itself, so there's no reason not to use it !

except that it doesn't copy file permissions and stuff like that.
here's a snippet from eserte that does that: http://board.perl-community.de/cgi-bin/ikonboard/ikonboard.cgi?act=ST;f=6;t=1758#idx3

File::Copy is portable to every OS perl runs on as far as I know, while cp and copy are not available on every OS. I tend to use File::Copy for all my copying needs.

On the other hand, I've worked on some solaris installs where Sys::Syslog was not available. YMMV.

In general, using modules is faster than forking off an external program, especially if you call a lot of them, but some external programs are more efficient than the equivalent perl module, especially when dealing with huge files.

- it might be that the program in question is restricted to interfacing with a non-portable system anyway

- some modules aren't portable

- the portability of other solutions within the same system may have been addressed in a way incompatible with the perl module.

- (etc.)

Moreover, assuming a module is indeed the best solution for the situation, modular design considerations suggest that you shouldn't plaster it's use all over your application, but rather make your own application as modular as possible by putting your own wrapper module round the usage of the perl module or set of related modules.

For example, instead of using Data::Dumper in every module and main program under the sun, you might consider having one module called MyDebug.pm that uses Data::Dumper and checks a global variable for whether or not your data debugging requirements are enabled.

The biggest benefit of this idea is when you find a requirement has to change, you want to be prepared by such techniques to minimise the modifications, instead of potentially searching and editing throughout an entire source tree.

Why use Perl at all? That, to me, is the essence of your question. If your Perl code is a sequence of system calls you could save yourself some grief with a shell script or batch file.

Certainly when you're starting in Perl a construct like
     $retval = system "logger -t PERLSEZ TIMTOWTDI Rulz!"
is a safe and familiar way to get the word out. So (to continue using this example) you can wonder why Tom and Larry bothered to code up Sys::Syslog and what they did to make it worth using. A quick check of the CPAN page shows that you can start by

use Sys::Syslog;
openlog "PERLSEZ", "pid", "LOG_MAIL"; # say it once and let Sys::Syslo
+g remember for the duration, save me some typing later
# add code as needed
[download]

  syslog "info", "spammer trying dictionary attack blocking  $ipaddr";
[download]

Sys::Syslog provides full control over logging. Note that you don't get to specify the facility, which log type, with /usr/bin/logger. Along with the full control your  openlog call will set up some global options so you don't have to specify them on each call. Handy. The other Perl replacements for varied  system "command [args]" have their unique advantages.

Best of all you get to do both. Use  system ...; until you have a frustration with what it won't do for you then investigate what Perl and CPAN have to offer for alternatives. Play with a few, choose the one that floats your boat and implement it.

#!/usr/bin/perl

use strict;
use warnings;

use File::Copy;

my ($src, $dest1, $dest2) = ("/tmp/f1", "/tmp/f2", "/tmp/f3");

# Create source file, give it execute permission.
open my $fh, "> $src" or die;
close $fh or die;
chmod 0755, $src or die;
die "No execute permission on source\n" unless -x $src;

# Make sure destination files are removed.
if (-f $dest1) {unlink $dest1 or die;}
if (-f $dest2) {unlink $dest2 or die;}

# Set umask.
umask 022 or die;
system "cp $src $dest1" and die;
die "Lost execute permission using 'system cp'\n" unless -x $dest1;

copy $src, $dest2;
die "Lost execute permission using 'File::Copy'\n" unless -x $dest2;

__END__
Lost execute permission using 'File::Copy'
[download]

OTOH, I've been using Sys::Syslog for many, many years.

I tend to use modules if they are good, they are not doing something different than what they are supposed to replace, and if they don't require more typing. I still use my $text = `cat file`; - it does what I need it to do, and it's short.