This piece of code doesn't seem to do much yet (is it meant to be pseudo code?)

Things to think about:

• Are you trying to run the executable remotely from another machine via CGI? and also pick up the file from off the web? (because this is what your file starting with "http://" makes it look like. If you want to do that I'd probably look at something like LWP::Simple - which makes it very easy to slurp in a file off the web.

  (Or were you meaning to tell the CGI the path to a file sitting on the same server as itself? - which is what your question seems to indicate. If so you would only need to give it the local path to the file as far as the CGI program was concerned (or more securely the name of a file sitting in a predetermined directory on the server where the program *always* looked for its files.)

• Your script starts off with use CGI; indicating that it is intended to be run as a CGI program itself - is that what you really mean? to run one CGI which calls another CGI? Perhaps you actually intend to run one CGI which executes a file locally (i.e. on the same server as the CGI script) instead? - if so, you wouldn't need to call it with "http://" - but would probably want to run it locally using open and a pipe like this:

# path to program
my $prog = '/local/path/to/cgi-bin/executableprog';

open(PROG, "| $prog") || die "Can't run '$prog': $!\n";
print PROG "$file\n";
close(PROG);
[download]

• Presumably where you have:

  my $pid = open PIPE, "-|";
  [download]

  and then:

  exec PROG or die "Cannot open pipe to executableprog: $!";
  [download]

  PIPE and PROG were meant to be talking about the same process?
• What's the stuff for a fork for? you're probably better off not worrying about forking (which is a little complex) until you get the basics of reading and writing files and running programs mastered.

Yes, PIPE and prog are meant to be talking about the same process. oh dear .. i have a lot to learn here.
OK ... well eventually I would like this program to be run as a cgi itself yes. But I'm not going to be running another cgi from this script, its a C program. Everything is on the same server, so perhaps I could run them locally then.
Thanks for the tips so far.
As for how I would run the program on the command line normally .. well I would type in the name of the program to start .. and then a prompt comes up asking me for the text file to process.

#!/usr/bin/perl -w
use strict;

my $in = <STDIN>;
print $in;

# END #

Now test it
> echo "Hello, world!" | ./test.pl
Hello, world!
>
[download]

CGI is insecure if you use input from the user to pass into a program. For example:



Insecure CGI example:
print "Enter a command to execute:"
my $command = <STDIN>;
system($command);   # BAD!

User enters 'rm -fR *' !!!
[download]



However, in your code above, you are not taking any input. You are simply executing a program and supplying it with a file. Based on your snippet, you would do this exact same thing at a command line. You aren't giving the user any choice of what to do.

CGI can also be dangerous is you allow someone to job off processes on your machines, like you are doing above. Is this a heavy duty process? If a user bounces on the refresh button, can they start a whole lot of these jobs, and eat up system resources causing poor performance and possibly a crash? That's a problem too. Have you dealt with that in your script?

OK ... I don't think the 'refresh' problem will arise.
The steps will be as follows:
A script that uploads the text file to a named directory on the server. This has already been written. This cgi script will then (hopefully) point to this script which will then call the external program.
The results of the external program will come though as a text file also.