If the plan is to use the output of another script as data in the current (CGI) script (e.g. as content to be included on a web page), the three possible ways to do that are:

# one way:

my $content = `other_script`;
die "No output from other_script" unless ( $content );

# another way:

open( SCR, "other_script |" ) or die "other_script failed: $!";
print while (<SCR>);
close SCR;

# the only other way:

my $tmpfile = function_returning_uniq_name();
my $status = system( "other_script > $tmpfile" );
die "other_script failed" if ( $status or -s $tmpfile == 0 );

open( TMP, $tmpfile ) or die "WTF?? can't open $tmpfile: $!";
print <TMP>;
close TMP:
unlink $tmpfile;
[download]

In terms of security, I think the three methods are equivalent (I hope others will correct me if I'm wrong):

If the name of "other_script" and any command line args that are needed are constants that you define in the source code (not derived from input CGI parameters), then there isn't much to worry about.

If the command line needs to be constructed on the basis of CGI params, then you need to be very careful about how you do this, no matter which method you use. Ideally, CGI params would only be used (via regex matches or value comparisons) to decide which script-internal, pre-defined constants -- or which server-internal, verifiable file/directory names -- should be included in the command line. If the app is supposed to allow CGI param strings to be included on the command line, apply the tightest possible untainting.

Regarding the 2nd, 3rd and 4th "alternatives" suggested in the OP, they won't work at all:

• The system call returns the exit status of the command line, not the stdout content.
• eval("script.cgi") returns the string "script.cgi"
• exec("script.cgi") does not return to the calling script -- the named command takes the place of the calling routine in the system's process table.

BTW, based on your proposed examples, you may need to take note: running a sub-process in a CGI script does not mean that the sub-process is "automatically" a CGI script itself -- it does not get the parameter values that the calling CGI script received, unless these are somehow (carefully) included in the command line or %ENV. You can run any command, more or less the way you would from an interactive shell on the server -- that's why you have to be careful.