system() calls another program, and then returns a status code (which contains the exit value of the program, and possibly information about signals). system() can be called in such a way that no shell will be used.

qx calls another program, and returns the output of that program. It's not under the programmers control whether a shell can be bypassed or not.

Both system and qx are implemented using fork and exec (at least, under Unix).

Abigail

Thanks, it's a nice explanation - clear and short, sums up the doc wonderfully :)

Using open() for IPC
       Perl's basic open() statement can also be used for unidirection
+al
       interprocess communication by either appending or prepending a 
+pipe
       symbol to the second argument to open().  Here's how to start s
+omething
       up in a child process you intend to write to:

           open(SPOOLER, "| cat -v | lpr -h 2>/dev/null")
                           || die "can't fork: $!";
           local $SIG{PIPE} = sub { die "spooler pipe broke" };
           print SPOOLER "stuff\n";
           close SPOOLER || die "bad spool: $! $?";

       And here's how to start up a child process you intend to read f
+rom:

           open(STATUS, "netstat -an 2>&1 |")
                           || die "can't fork: $!";
           while (<STATUS>) {
               next if /^(tcp|udp)/;
               print;
           }
           close STATUS || die "bad netstat: $! $?";
[download]

use IPC::Open3;
 $pid = open3(\*WTRFH, \*RDRFH, \*ERRFH,
                           'some cmd and args', 'optarg', ...);
[download]

Thanks for the reply - i had read about that one in the doc too ... TMTOWTDI, definitly !!!!

What if you want the messages that your subprocess generates to go to your STDOUT (which, perhaps, is going to a log) as it is generated? (With `` you'll not get any output until the program has completely finished, so no partial progress information is provided.)

Both of these are good reasons to use system or exec instead of backticks.

And even if none of these stand, qx captures and saves the output in memory, thus it can eat too much memory unneccessarily if you discard the output. (A make command can have several megs of output to stdout.)

And even if none of these stand, qx captures and saves the output in memory, thus it can eat too much memory unneccessarily if you discard the output.

Uhm, no. Testing seems to indicate qx// is context aware, and doesn't store anything in void context. Running:

perl -wle '`perl -le "print q!*! x 1_000_000 while 1"`'
[download]

doesn't consume much memory, but running

perl -wle '$_ = `perl -le "print q!*! x 1_000_000 while 1"`'
[download]

quickly consumes all memory available.

Abigail