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.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.