The simplest thing would be to use system or one of its variants (backticks, exec, etc.). E.g. if your other CGI script is called foo.pl and it's implemented with CGI:

my $cgi_script = 'foo.pl';
my @args = qw( bar=baz quux=frobozz );
system( $cgi_script, @args ) == 0
  or die "call to $cgi_script failed: $?";
[download]

But I think this is a fragile design. A better alternative would be to refactor the functionality of the script that you want to call into a function, and define a module around this function that the first script can load (with use or require or do). And once you do this refactoring, what used to be the "second" CGI script in this story would become a wrapper around the core module. You'd ultimately end up with two CGI scripts calling the same module.

Just to nitpick a tad, your example will only work if $cgi_script is a perl module using the CGI module (or perhaps some other library that implements CGI's non-standard debugging input). CGI scripts don't read *any* arguments from ARGV, they read from $ENV{QUERY_STRING} for GET type requests and STDIN for POST type requests.

So if you really wanted to use system, you would probably want something like:

#assuming $cgi_script and @args
$ENV{QUERY_STRING}=join'&',@args;
my $resp = `$cgi_script`;
[download]

Thanks. I'll try that

Or, since you just want to pass a single piece of data, you can pass it directly via system / ARGV or GET query / QUERY_STRING. Though depending on what you want to do (process your variable with a sub in a secondary script?), it might make more sense to use or require or do, like tlm suggests above.

Snippet from first script

($percent_alpha) =CalculatePercentage($alpha, $totalresidues);
[download]

I now want to pass the variable $percentage_alpha to another CGI script for further processing. So ... basically passing from one CGI script to another.

Does that make sense?

You want one script to output HTML, such that when a user does something, the value the first script computed will be passed on to the second script?

If so, you can do two different things, depending on what "does something" means. If you want the user to fill out another form, and hit the submit button again, then use an input tag, with it's type attribute set to hidden -- the HTML spec has details.

---

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

The term "CGI Script" is not a well defined concept it seems.

All it means is that it is a "script" which implements the Common Gateway Interface, being a protocol about passing data about the information request from the server to the script. This can be done through environment variables (the "GET" mode) or through STDIN (the "POST" mode) or through the command line (the "ISINDEX" mode). STDOUT is used for returning info from the script to the server (which might relay it to the client -- although that falls outside of the CGI protocol).

So the only way you can speak to a CGI script (which can be written in any language) is through "GET" or "POST" (we forget conveniently about the ISINDEX command line mode). Any other way of speaking to the "CGI script" (e.g. calling it directly as a subroutine or module or ...) does not use it as a CGI script but as a Perl, PHP, VB, ... program and will have to follow the rules for calling such programs. So strictly speaking there is no way under the CGI protocol to call a subroutine which lives in another CGI script. CGI scripts are, seen from the server, monolithic; they have one entry point, get their input from "GET" or "POST" and return their data through STDOUT. Whether the CGI script is one bunch of spagetti code or consists of 1,000 subroutines in 100 modules, is totally transparent for the caller. Unfortunately for your purpose it is also opaque: you can't see or access its parts separately.

So if you want to call another CGI script from within a CGI script you must launch a new request to the server (modules like LWP or WWW::Mechanize spring to mind). Still you will only be able to call this other CGI script as a whole.

If however you just want to call a subroutine which resides in another script or module or program, this has nothing to do with CGI at all and it is in no way different from useing, requireing or doing a subroutine in such used, required or done script, module or program (see use, require, do), provided of course these scripts, ... reside on the same server, are written in Perl and you have the necessary privileges to access them.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law