in reply to Passing arguments to a background process...

I'd drop the question mark from the command line to solve your problem, but then, why should you use a CGI interface for the program you're launching in the background?

Apart for this, I' don't like much the idea of launching another process from a web page. You sure there is no smarter way to do it, like having a process running and queuing requests to it? As you don't know when the process will end, I presume what you need to do is not synchronous. You could just add a flag on a table (or write a flag-file in a directory) and then a single process would look for existing flags and process them one at a time.

This has the adventages that you 'pay' for program startup only once (process creation and code compilation, if it's in Perl), you have no racing conditions to take care of, and you can write readable logs (as it will process one thing at a time), and as you have only one instance running there is only one copy of the program in RAM at a given time.

My 0.02 euros

  • Comment on Re: Passing arguments to a background process...

Replies are listed 'Best First'.
Re: Re: Passing arguments to a background process...
by aquarium (Curate) on Dec 05, 2003 at 11:20 UTC
    i think you need to learn the difference between a cgi program, which is a program that processes and/or generates web pages, and a normal (non-cgi) program. A CGI program takes its' parameters from HTML forms and receives them via param{'var_name'} call. This is the CGI interface. When you are calling your background process directly from another program, the interface is standard (not redirected) input/output and @ARGV to get at arguments passed to it. Mind you, you have to be very careful in the design of both the CGI program and your background process, as the web users will potentially create many instances of those programs in memory simultaneously. Therefore, if your programs deal with any files, they must be written as not to interfere with each other or corrupt files. I recommend that you borrow/buy a book on perl CGI to learn a great deal more....CGI programs, i.e. perl programs that "use CGI;" have their standard input,output,and error handles re-directed. it's like switching from programming for a console app. to a windows based app., input/output and standard arguments are handled differently.
[reply]
      Thanks very much for your replies. 

I will look into the options in more detail and work on it.

I like the option of using a file or table and let only 
one instance of the program running. 

I might have said it wrong when I said that I want to run 
a CGI program in batch. It is just a perl program. 

I tried using the @ARGV and STDIN, but I was not 
successful in transfering the data. I was able to pass the 
file name, but not a variable with data or data itself. 
Can you give a sample code or how to use these to pass 
parameters (data or variable) to other program than the 
file names.  

Thanks very much for you help!
[reply]
        As said before, put this at the begining of your script (after the SheBang...

        use <a href="http://search.cpan.org/search?mode=module&query=Getopt%3A
+%3ALong">Getopt::Long
</a>;

        [download]

        And you'll manage all kinds of inputs.

        You might have to read the perldoc...

        >perldoc -m Getopt::Long

        [download]

        It does magic at CLI like CGI does at a WWW server.

        If you cannot get it, it's not you, it is that you might need some reading. Perl is quite easy once you know all the basic syntax.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom