If you wrote modulinos instead of scripts or *better* used a framework like CGI::Application or Dancer or Mojolicious, you could get away with keeping everything in one process. While I *love* the unix way and pipelining, I don't think it's a good approach for *most* web programming tasks.

Thank you very much for your reply.

Indeed, I did not know about modulinos. This technique is very interesting. It seems that it resembles the way I have done it now (see above).

Regarding the frameworks: I admit that I don't like them very much because most of them are not flexible enough for what I want to do, or the learning curve is very steep. Every time I tried a framework or read the documentation of a framework, I have come to the conclusion that it would take more time to learn the tricks to break its limitations than the framework would save, or that the framework's philosophy was not mine.

To make a long story short: Frameworks are not appropriate for me. I am very happy with putting my well-tested methods in several modules and use these modules from my applications.

By the way, the same applies for the template systems. I have written my own template system which might not be appropriate for the mass market, but is very simple and just does what I want, thereby keeping maximum flexibility (i.e. I can write pure perl code without any restrictions in my HTML pages).

Since your answer contains some very interesting hints, I have voted it up, although I have chose another solution.

Regards,

Nocturnus

I surely would have to write code which encodes the form data for the command line (all character sequences which might be treated specially by the shell would have to be transformed), and the form data might be very long, even longer than the maximum length which is allowed for a command line.

You could use CGI

SAVING THE STATE OF THE SCRIPT TO A FILE:

    $query->save(\*FILEHANDLE)
[download]

my $q = CGI->new(\*IN);
[download]

Thank you very much for your reply.

I just did not know that the CGI module is able to do that. In the past, I have used the CGI module heavily and thought that I would know the most important things about it, but this obviously was an error.

I have tested your proposition, and it works great. But now, there was the problem how to tell script B.pl from where it should read the parameters (HTTP form data or file / STDIN). That was easy to solve, though:

A.pl will call B.pl with an additional command line parameter. If B.pl finds this command line parameter when called, it knows that it has been called from another script and that it should read STDIN for the CGI data; otherwise, it knows that it has been called directly from the user's browser and that it should read the CGI data from the HTTP data.

Thanks again,

Nocturnus

There's another option: you could use a module like LWP::UserAgent in ScriptA.pl to talk to ScriptB.pl through its URL. That way you can pass the parameters just as a browser would pass them, and ScriptB.pl doesn't have to be changed at all. ScriptA.pl just has to take the output of ScriptB.pl and do whatever you had in mind for it.

Thank you very much for your reply.

Your solution has the advantage that script B.pl even could be on another server than script A.pl. But in this case, I don't need this feature, so the disadvantage of being "expensive" in networking terms outweighs the advantage.

Therefore, I have chosen another solution (see above). Nevertheless, I have voted up your proposition because it surely will work and has an additional interesting feature.

Regards,

Nocturnus

Thank you very much for your reply.

Although I have chosen another solution (see above), I have voted your proposition up since I think that it could do what I asked for (I did not test, though).

I didn't chose your solution because I generally don't like redirects very much (they sometimes seem to cause problems with search engines and other sorts of problems), and that they seem to be "expensive" in network terms.

Nevertheless, thank you very much again for a solution that quite probably will work.

Regards,

Nocturnus