Anything that forks off, or executes an external program can be unpredictable...... but I would rather have it easy to use and test it myself before use, than have Perl prohibit me from doing it, like in cgi taint mode.

The testing for correctness extends further too, when you pass in an @args, like system('/bin/foo',@args), how can you be sure how foo is parsing @args? I've seen weird input processing where you need to explicitly specify input pairs, like system('/bin/foo','-p bar','-z wham', '-x ','one two three')

So in other words, Perl makes it easy for 99% of cases, but you need to be careful, and it's up to the programmer to watch for errors, with something along the lines

system("cmdtorun,@args >error.txt 2>&1");
[download]

I have this snippet saved from ChemBoy which may be useful

#!/usr/bin/perl

#by ChemBoy of perlmonks
# Ever gotten annoyed at how different from every other subroutine 
# call system is? Ever screwed up your error reporting because you 
# couldn't remember what to do with $?, $@ and $!? I sure have... 
# and I got sick of rewriting this over and over, so I wrapped it 
# in a utility subroutine, and here it is. It assumes the 
# system LIST style is being used, because system SCALAR is 
# somewhat hazardous and (IMO) to be discouraged, but obviously 
# it's readily modified to be more tolerant.

# Usage:
# wrap_system(qw(perl -u -e 1)) or die "$@\n"
# perl exited with status 0 after receiving signal 6 (core dumped)

wrap_system(qw(perl -u -e 1)) or die "$@\n";

sub wrap_system {
   if ( 0 == system { $_[0] } @_ ) { return 1 }
   if ( -1 == $? ) {
       $@ = "Unable to launch $_[0]: $!"
   } else {
       $@ = "$_[0] exited with status " . ($? >> 8);
       if (my $sig = $? & 127) { $@ .= " after receiving signal $sig" 
+}
       if ($? & 128) {$@ .= " (core dumped)" }
   }
   return;
}
[download]