Charles Galpin wrote: > Hi TED > > there is no silver mod_perl bullet. I would start here > > http://perl.apache.org > > Als, your description below of the cgi process is a bit warped (or you are > using it in a warped manner) :). > > charles > > On Sat, 15 Apr 2000, p-thilts wrote: > > > With a lot of help I've now arrived at a detailed procedure that builds > > from sources Apache, mod_perl, PHP( which can access the PostgresSQL and > > MySQL databases), as well as the database themselves (Server, Client, > > and Development). The tar files from the RH6.2 rpm source files were > > used (except for MySQL which was downloaded) because relocation of the > > source and builds was an issue. Most of this has been tested and > > appears to work fine. However, I am clueless as to how to actually test > > mod_perl. Up till now I have used the CGI. Here is an example of how I > > did it using CGI before mod_perl. > k > > -- > To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" > as the Subject. Charles: Here is all I was trying to say: ===================== So let me rephrase. Do I still use the same kind of submit operation associated with a form on a browser web page (where the submit bundle of information references CGI or cgi-bin) in order to evoke the apache operation of mod_per? Should have said it that way in the first place. Regarding your response - please let me explain. =================================== I'm not sure if you were about to provide more information or you just included the first paragraph and wanted me to read perl.apache.org. I will read perl.apache.org but to clarify: What I was doing was using CGI to execute a bash script. It was part of a development exercise. It was probably a mistake to site that example, but it was something I had in front of me at the time. Activating a bash script via CGI is in itself is not warped. CGI can be used to set up execution of compile code, perl code, etc. , which I and thousands of others do for production system operation. When working with a web page containing a form with a submit button - when the button is clicked, the browser sends a bundle of information to the web server. The web server detects (based on the content of this information bundle) that the CGI is involved and that a specific code package will have to be executed. I'm assuming you are not calling a standard CGI process warped so you must be refering to the use of a bash script to run a perl script warped. Depends on the rationale. My scenario (given in the example) is purely developmental. It is not intended to be a production example. The example has become an issue which was not the intent. It's just that I was talking about perl and probably should not have provided that example which was in front of me at the time. There is a developmental reason for wanting a bash script to be executed. The bash script manages the perl scripts. I was doing developmental exercises with these scripts and with the bash decision making because I wanted to make a number of decisions in the bash script before executing any perl scripts in order to help my development exercises. I was using the server, CGI, and bash scripts as development tools not as production code. I'm not going to get into this in detail. I think that is what my example shows (but none of the rationale) therefore, I don't see anything warped about it - once one knows the rational. However, I did not provide the example as a desireable way of doing things in a production environment but rather to show that I needed a way of evoking the apache built in mod_perl module from a submit situation involving a form on a web browser. I should have just said that. My explanation, however, was that I knew how to evoke the CGI (as in my example which I now regret providing) but I DID NOT KNOW HOW TO EVOKE THE MOD_PERL interface. For example, do I still use a reference to CGI in the bundle of information going from the web browser submit and expect apache to automatically process via mod_perl? That's the only real reason for that particular example. Certainly I would not feed that example to mod_perl and certainly I would not use that example in a production scenario. However, for development purposes, there is nothing wrong - as far as I know - in using a bash script via CGI to do primary processing of data (security issues set aside for the moment). Moreso, from an efficiency standpoint the CGI sets up a process and then the bash script sets up a process and so on. Not efficient. A busy server would probably go down with so many spawned processess. From that standpoint, one would probably never do that in a production environment - it would be stupid. So I was using the server CGI and the bash scripts as tools to help development exercises with perl and other script/code. Next time I will be more careful about the examples I provide. So let me rephrase. Do I still use the same kind of submit operation associated with a form on a browser web page (where the submit bundle of information references CGI or cgi-bin) in order to evoke the apache operation of mod_per? Should have said it that way in the first place. Bye-thanks_TED -- To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject.
