I need to have a script that sends info from a form to a db and then sends info to another script. It would be great if anyone could help me even if it is just being pointed in the right direction. I don't need the exact code.

1) If you want anyone with a pc to be able to execute a script then put it in the cgi-bin directory. If you don't, then you better locate it in a non publicly accessible directory.

2)

Quote

If both scripts reside in the url folder I showed above, wouldn't the relative path be just the script name?

You need to learn some basic terminology. There are urls, and there are paths, and there are folders/directories, but there is no such thing as a url folder. If you do not use common terminology, then no one will have any idea what the hell you are talking about.

3)I've tried all these:

../cgi-bin/surveys/"script" ../surveys/"script" ../"script" "script"

And what made you decide to put quotes around "script"?

4) If you want to execute things on a server, then it would help if you knew what the 'root directory' was on your server. Then you can construct absolute paths from the root directory. You can also fiddle around with relative paths, but it is nice to be able to fall back on an absolute path when you can't figure out the relative path.

5) If you want help on figuring out the paths, start off by posting what server you are using.

# the result of this next line surprised me, # which is why I also passed the string in the open call say $pipe $str;

Is the parent or the child executing that statement? There is a difference between a 'pipe open' and a 'fork open'. You haven't handled the 'fork open' correctly. Even if you had, simpler is better, and a pipe open is all that is called for in the op's situation. I did overlook a problem with the 'pipe open' that needs to be handled--the case when the script being opened doesn't exist, which is particularly relevant here because the op's script doesn't actually exist due to path problems.

According to perlipc, when the script specified in the the 'pipe open' doesn't exist, the 'pipe open' will still succeed. Subsequently writing to the pipe will cause the cgi script to blow up when it receives a PIPE signal--which is sent to the cgi script when it tries to write to a pipe that has been closed. Closed pipe? But the 'pipe open' succeeded?! Yeah, but according to perlipc the fact that the 'pipe open' succeeded doesn't actually mean the pipe was ever opened. Confusing. The cgi script will only discover that the pipe wasn't opened successfully when the cgi script tries to write to the pipe.

Also of note is that the PIPE signal may only get sent to the cgi script after the cgi script calls close() on the pipe. Calling close() on the pipe causes the output buffer to be flushed, which then actually writes the output to the pipe.

To protect the cgi script from terminating due to a PIPE signal, you should add the following before the 'pipe open':

For three or more arguments if MODE is '|-' , the filename is interpreted as a command to which output is to be piped, and if MODE is '-|' , the filename is interpreted as a command which pipes output to us. In the 2-arguments (and 1-argument) form one should replace dash ('-' ) with the command.

I've never seen a pipe open written using that format. When I see '|-', I associate that with a 'fork open'--as described in perlipc section Safe Pipe Opens. In any case, either format for a 'pipe open' works for me in the script I posted (on unix like mac osx 10.4.11).

If you were attempting to pass the data to the other program as a command line argument, then according to perlopen you can do that using the 4-arg open():

(I was using "script" to stand for the actual script for purposes of this thread.)

both scripts reside in the 'surveys' directory in the cgi-bin. The first script is 'survey_REC.pl' and it opens a pipe to script 2; serve_survey_indv.pl and is supposed to pass two arguments to script 2; $survey_name and $x. Script 2 should take the two arguments and execute, which should display a form containing the two arguments.

I apologize for my lack of terminology. This is as best as I can explain it as I am still learning and, as is evident, will for a long time.

I was hoping not to combine the scripts since they are both rather long but I think combining the the two is the answer as you point out, FishMonger.

The scripts are long because they handle several options as well as write to a couple of dbs. Both scripts search a db, display info and then store responses into other dbs. So they get long.

The process happens between the two scripts back and forth as it collects information required to construct a survey. It is similar to Survey Monkey but more specific to our site and a bit narrower in scope.