On Thursday, June 27, 2002, at 07:01 , Imtiaz ahmad wrote:
[..]
> Using web based tool (CGI) a user selects a folder and once the
> user submits the script1 on the resulting page supposed to have a call to
> another script2. Script2 contains code that takes the folder name
> submitted
> and creates three additional file for each file in the folder.
> After script2 finishes then script1 copies files from the source machine
> to
> all the specified
> servers using RSYNC.
[..]
basically you have three types of issues - wrapping the front
end in CGI.pm really only says that your front end does not
in itself have to work out the issues of taking command line
arguments - so that part is in your Script2.
a) How do I call another programme
b) How does my other programme read my arguments
c) How does the caller deal with the 'results' of the called code
as we like to say
perldoc -f system
is one of the ways to do this
perldoc perlopentut
and of course
perldoc Getopt::Std and perldoc Getopt::Long
I put it this way as you could do the simple 'backtick' tricks
but I am less enamoured of them than the standard 'system()' or
"open" tricks - cf:
http://www.wetware.com/drieux/pbl/Sys/DealingWithErrorsInSys.txt
A part of the issue you will clearly want to get your head around
is the problem of how to deal in 'script2' with brining in the
arguments - and some way over the top issues are addressed in
http://www.wetware.com/drieux/pbl/Sys/NextStuff/getOptStd.txt
For the Completely Over the Top Approach of looking at how
code_a | code_b would work then you of course want to look
at something like:
http://www.wetware.com/drieux/pbl/Sys/NextStuff/A_pipes_to_b.txt
As you will note these last two URL's show the 'high weirdness'
of 'building' the script and forking it out there through 'open()'
You can of course save some of the overhead by having it in
the system to begin with.
If you already have Script2 - then you merely need the intermediary
glue of your friend system/open - If you have not actually built
Script2 - this would also be the time to ask yourself why spawn
an exterior piece of code to manage this??? Why not think in
terms of making a 'sub' that deals with all of this????
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
