RE: CGI Scripts w/mod_perl
Hi all, On Fri, 26 Jul 2002, Mark Coffman wrote: Try running which perl and use that path for your #!/usr/bin/perl line. Then rename your script as .cgi and see if that helps. Of course none of this absolves Christina from reading the Eagle Book, the mod_perl Guide, the Cookbook (Geoff - see that?) and truckloads of other stuff which you will be able to find through the mod_perl site http://perl.apache.org when you do actually start to use modperl. For example you can find out how to run mod_perl and non-mod_perl applications under the same Apache which isn't a bad way to get your feet wet. 73, Ged.
RE: CGI Scripts w/mod_perl
Try running "which perl" and use that path for your #!/usr/bin/perl line. Then rename your script as .cgi and see if that helps. Mark -Original Message-From: Christina [mailto:[EMAIL PROTECTED]]Sent: Friday, July 26, 2002 9:32 AMTo: [EMAIL PROTECTED]Subject: CGI Scripts w/mod_perl Hi, I installed a CGI script last night, only to later realize the server is running mod_perl, instead of Perl. I have never worked with mod_perl before,so I'm wondering if this is why the script won't function on the server. The script calls for a change in the first line of the code in all .pl files if the path to perl is different from #!/usr/bin/perl, but I can't find anything in the server to indicate what the path should be using mod_perl. I am completely confused at this point so any guidance in the right direction would be greatly appreciated! Thanks, Christina
RE: CGI Scripts w/mod_perl
On Fri, 26 Jul 2002, Mark Coffman wrote: Try running which perl and use that path for your #!/usr/bin/perl line. Then rename your script as .cgi and see if that helps. Um.. yeah, ignore all my locate tribble. 'which' is the way to go. That wasn't a question.
Re: CGI Scripts w/mod_perl
I'm sending out the sincerest of thank you's to all of you who helped me with my problem earlier today! I was offline most of the afternoon, but found your messages this evening and miracle of all miracles, I actually got the script to work. Thanks everyone! Christina - Original Message - From: Mark Coffman To: Christina ; [EMAIL PROTECTED] Sent: Friday, July 26, 2002 9:43 AM Subject: RE: CGI Scripts w/mod_perl Try running "which perl" and use that path for your #!/usr/bin/perl line. Then rename your script as .cgi and see if that helps. Mark -Original Message-From: Christina [mailto:[EMAIL PROTECTED]]Sent: Friday, July 26, 2002 9:32 AMTo: [EMAIL PROTECTED]Subject: CGI Scripts w/mod_perl Hi, I installed a CGI script last night, only to later realize the server is running mod_perl, instead of Perl. I have never worked with mod_perl before,so I'm wondering if this is why the script won't function on the server. The script calls for a change in the first line of the code in all .pl files if the path to perl is different from #!/usr/bin/perl, but I can't find anything in the server to indicate what the path should be using mod_perl. I am completely confused at this point so any guidance in the right direction would be greatly appreciated! Thanks, Christina
Re: Both global hanlder and cgi scripts
On Tue, Oct 09, 2001 at 11:38:10AM +0200, Mat wrote: Hi everybody, actually i'm working on a website where I want to have the following possibilities : - a global handler that will treat a request hitting http://myhost.com/ - the ability to have execution of separate cgi scripts like http://myhost.com/script.cgi I had some trouble with this, and found a workable solution, for the Navbar handler from the eagle book: Files ~ \.htm* SetHandler perl-script PerlHandler Apache::NavBar PerlSetVar NavConf /etc/apache/perl/navigation.conf /Files Substitute the Files directive for the Location / and this should work. This works against .html and .htm files That's all I had for content on that server so it works great for me. -- Nate Campi [EMAIL PROTECTED] GnuPG key: 0xC17AEF79 http://www.campin.net
Both global hanlder and cgi scripts
Hi everybody, actually i'm working on a website where I want to have the following possibilities : - a global handler that will treat a request hitting http://myhost.com/ - the ability to have execution of separate cgi scripts like http://myhost.com/script.cgi I have the following configuration in httpd.conf : (the AddHandler cgi-script .cgi is set) VirtualHost _default_:80 ServerAdmin [EMAIL PROTECTED] ServerName www.myhost.com DocumentRoot/home/webmaster/www/myhost.com ErrorLog/usr/local/apache/logs/error.log CustomLog /usr/local/apache/logs/access.log common ## mod_perl stuff PerlTaintCheck Off PerlFreshRestartOn PerlRequire /home/webmaster/scripts/startup.pl ## allow cgi's here and there Files *.cgi PerlSendHeader Off PerlHandler Apache::Registry SetHandler perl-script Options +ExecCGI /Files ## handler stuff for the index Location / SetHandler perl-script PerlHandler TOL::Index /Location /VirtualHost so when the / is hit my module takes over and display the page perfectly. But when I try to call the cgi scripts, it displays my code and doesn't execute it. I searched the archive for this problem and found the following post http://groups.yahoo.com/group/modperl/message/33720 which talks about using FilesMatch, I tried but it didn't work. I'd like not to use a specific directory to put my scripts in (with Alias or Script Alias directives) and like to know if there is a simple of doing what i want. Thanks. Mat ps: i'm using apache 1.3.20, mod_perl 1.26, perl 5.6.1, no messages in error logs.
Porting CGI scripts help needed
Hi, I have (happily) compiled and configured Apache with mod_perl, mod_ssl, mod_php and DSO. Whee! Now I am working on porting my scripts over... I have always used strict and perl -w, so for the most part, I think I can just pop my cgis in the /perl directory as Ive defined it in httpd.conf. However, I had to implement some trickery for my scripts a while ago via require/use and am having problems getting my scripts to work. Heres what I did: I had many scripts in one dir that shared many things; subroutines, global variables and modules. I wanted to clean things up, so I created a module called global.pm structured like this: --- use strict; ## Local parameters our $cgibin = http://path/cgi-bin;; our $htmldir = /apache/htdocs our $a = /some/path; our $b = /some/other/path; ## Common modules use CGI qw(:standard); use DBI; use Data::Table; ## Custom stuff require /path/to/custom/script1.pl; require /path/to/custom/script2.pl; 1; --- The custom stuff scripts all end in 1;, and are loaded with my custom subroutines. For example, I have one called cgi.pl, that contains all subs for cgi related tasks, i.e. checkUser(), which verifies a users cookie. Each cgi simply calls 'use global;' and then off we go. However, after moving all this stuff into /perl, none of the subs in the custom .pl files are found, I get a complaint: Undefined Subroutine Apache::ROOT::compar_2ecgi::checkUser called at . compare.cgi calls 'use global;' and then 'checkUser()'. What am I doing wrong with this? Any ideas? Thanks! Bryan
RE: Porting CGI scripts help needed
You might try adding use lib '/path/to/global.pm'; to you startup.pl. (Without the s of course) Good luck. --Joe Breeden -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: Bryan Coon [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 26, 2001 6:01 PM To: '[EMAIL PROTECTED]' Subject: Porting CGI scripts help needed Hi, I have (happily) compiled and configured Apache with mod_perl, mod_ssl, mod_php and DSO. Whee! Now I am working on porting my scripts over... I have always used strict and perl -w, so for the most part, I think I can just pop my cgis in the /perl directory as Ive defined it in httpd.conf. However, I had to implement some trickery for my scripts a while ago via require/use and am having problems getting my scripts to work. Heres what I did: I had many scripts in one dir that shared many things; subroutines, global variables and modules. I wanted to clean things up, so I created a module called global.pm structured like this: --- use strict; ## Local parameters our $cgibin = http://path/cgi-bin;; our $htmldir = /apache/htdocs our $a = /some/path; our $b = /some/other/path; ## Common modules use CGI qw(:standard); use DBI; use Data::Table; ## Custom stuff require /path/to/custom/script1.pl; require /path/to/custom/script2.pl; 1; --- The custom stuff scripts all end in 1;, and are loaded with my custom subroutines. For example, I have one called cgi.pl, that contains all subs for cgi related tasks, i.e. checkUser(), which verifies a users cookie. Each cgi simply calls 'use global;' and then off we go. However, after moving all this stuff into /perl, none of the subs in the custom .pl files are found, I get a complaint: Undefined Subroutine Apache::ROOT::compar_2ecgi::checkUser called at . compare.cgi calls 'use global;' and then 'checkUser()'. What am I doing wrong with this? Any ideas? Thanks! Bryan
RE: Porting CGI scripts help needed
Heres what I did: I had many scripts in one dir that shared many things; subroutines, global variables and modules. I wanted to clean things up, so I created a module called global.pm structured like this: snip The custom stuff scripts all end in 1;, and are loaded with my custom subroutines. For example, I have one called cgi.pl, that contains all subs for cgi related tasks, i.e. checkUser(), which verifies a users cookie. Each cgi simply calls 'use global;' and then off we go. However, after moving all this stuff into /perl, none of the subs in the custom .pl files are found, I get a complaint: Undefined Subroutine Apache::ROOT::compar_2ecgi::checkUser called at . compare.cgi calls 'use global;' and then 'checkUser()'. global.pm isn't exporting the symbol names it's defining. if you were to refer to global::checkUser() in one of your scripts, and it worked, then mebbe an EXPORT() list for global.pm is in order so that the function names get defined in the package (Apache::ROOT::compar_2ecgi, made up by apache on the spot) that is accessing them. HTH! L8r, Rob
RE: umable to run cgi scripts under mod_perl
you need to close your script with a END. -Original Message- From: Ratan Jha [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 13, 2001 06:33 To: [EMAIL PROTECTED] Subject: umable to run cgi scripts under mod_perl Running mod_perl-1.22 apache-1.3.11 I want to run plain perl scripts under mod_perl using Apache:Registry. I amke a change to my httpd.conf file Alias /perl/ /usr/local/apache/perl/ Location /perl SetHandlerperl-script PerlHandlerApache::Registry Options +ExecCGI PerlSendHeader On /Location I've stored my perl script in the perl directory under ~www/perl The perl script is: #!/usr/bin/perl print END; html body h1This is a test/h1 /body /html The file is being returned as a plain html file The output is: #!/usr/bin/perl print This is Test END Do you have any idea why is this happening? I'll appreciate your response. Thanks Ratan Ratan M. Jha Patni Computer Systems Ltd.(PCS) Unit 55, SDF2, SEEPZ, Andheri(E), Mumbai. Call - 8291454/0479 x 5178. E- mail - [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
umable to run cgi scripts under mod_perl
Running mod_perl-1.22 apache-1.3.11 I want to run plain perl scripts under mod_perl using Apache:Registry. I amke a change to my httpd.conf file Alias /perl/ /usr/local/apache/perl/ Location /perl SetHandler perl-script PerlHandler Apache::Registry Options+ExecCGI PerlSendHeader On /Location I've stored my perl script in the perl directory under ~www/perl The perl script is: #!/usr/bin/perl print END; html body h1This is a test/h1 /body /html The file is being returned as a plain html file The output is: #!/usr/bin/perl print
Re: umable to run cgi scripts under mod_perl
Hi there, On Tue, 13 Mar 2001, Ratan Jha wrote: Running mod_perl-1.22 apache-1.3.11 #!/usr/bin/perl print END; html body h1This is a test/h1 /body /html But where's the END? 73, Ged.
Re: cgi scripts
Hi there, On Tue, 19 Dec 2000, Mike Egglestone wrote: ScriptAlias /cgi-bin/ /var/www/Scripts/ ...and later down the file AddHandler cgi-script .cgi Look for mention of the ScriptaAlias directive in http://perl/apache.org/guide Options ExecCGI FollowSymLinks You might want to investigate the use of '+' in front of those. I'm thinking that the script isn't being executed by perl ... It's that Guide again! gotta hunt through those docs again Start with the one entitled "SUPPORT". It comes with mod_perl. Then the Guide. (You'll be a while, reading that:) 73, Ged.
cgi scripts
Hi all.. I'm very new to apache and perl... but I'm stuck with a web page that has some .acgi and .cgi files I'm running potato and did an apt-get install apache-perl... It wiped out my apache and perl seperately(early installs) That seemed good... everything seems good except for those scripts These are the changes I made to the default srm.conf and access.conf files... ScriptAlias /cgi-bin/ /var/www/Scripts/ ...and later down the file AddHandler cgi-script .cgi This is the change in the access.conf: Directory /var/www/Scripts/ AllowOverride None Options ExecCGI FollowSymLinks /Directory I think thats it.the web page stuff is in /var/www/ and along with some other junkgifs and such... the Scripts folder in there has some other folders with other .cgi and .acgi files kicking around... I've checked the permissions.. I think they're fine If I try http://localhost/cgi-bin/blahblah.cgi... I get an Internal server error. or if I try a couple folders past /cgi-bin/. .cgi same thing I'm thinking that the script isn't being executed by perl ... I figure I'm missing something in my conf files... gotta hunt through those docs again Any help on this matter is greatly appreciated Mike
Re: CGI scripts mod_perl
"GB" == Gunther Birznieks [EMAIL PROTECTED] writes: GB Apache::Registry programs are basically compatible with Velocigen, GB PerlEx, and SpeedyCGI acceleration. I think that's a huge GB commercial and open source advantage for anyone writing web GB programs for sale or open community use. And most of them can still run as traditional fork/exec CGI's for the occasion where you need to use it on another server. I think I've written exactly *one* direct handler (other than for hire), and that was just for learning how to do it. I use Registry all the time and see no reason not to continue using it. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts mod_perl
On Mon, 20 Nov 2000, Gunther Birznieks wrote: Most normal applications do not require every bit of speed eeked out of them that may be possible with an Apache handler. In the mod_perl guide, a reasonably fast machine (which most production mod_perl sites run on) shows very little time difference between a real-world app (what I would categorize the heavy Apache::Registry vs heavy hander) running in Apache::Registry versus being written as a handler. We've already discussed this one into the ground, but for anyone here who hasn't heard all this before, the main reason to use handlers instead of Registry is to avoid the odd compromises caused by writing something that is going to be wrapped in a generated package name and eval'ed into a subroutine. It's a pretty cool trick, but it's also limiting. For example, not being able to use subroutines unless you put them in an external module is troublesome. I also use handlers invoked as class methods so that I can do some inheritance stuff in my modules. I don't think Apache::Registry can deal with that at this point. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts mod_perl
| How do we make sure regular CGI scripts are using mod_perl???
| Is there a way to find out?
Check $ENV{MOD_PERL}, it should read something like "mod_perl/1.24".
Ime
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts mod_perl
on 11/19/00 4:55 PM, Ime Smits at [EMAIL PROTECTED] uttered the following:
| How do we make sure regular CGI scripts are using mod_perl???
| Is there a way to find out?
Check $ENV{MOD_PERL}, it should read something like "mod_perl/1.24".
Can I assume that whenever mod_perl is enabled that all existing perl
scripts use it without any modification of any kind?
I tried this in a simple script on both systems where I installed mod_perl
and there is nothing in that variable on either system.
Isn't there any way to find out if mod_perl actually works?
I see nothing special in any logs about this, but a status and info on
apache shows mod_perl enabled, and the few perl directives I inserted in the
httpd.conf aren't making a fuss, so I assume mod_perl is parsing them
properly...
--
Didier Godefroy
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts mod_perl
"Didier" == Didier Godefroy [EMAIL PROTECTED] writes:
Didier on 11/19/00 4:55 PM, Ime Smits at [EMAIL PROTECTED] uttered the following:
| How do we make sure regular CGI scripts are using mod_perl???
| Is there a way to find out?
Check $ENV{MOD_PERL}, it should read something like "mod_perl/1.24".
Didier Can I assume that whenever mod_perl is enabled that all existing perl
Didier scripts use it without any modification of any kind?
Not at all. Apache::Registry is a good stop-gap, but you have to play
by a number of useful and documented rules.
When you're *really* good with mod_perl, you abandon Apache::Registry
and move up to writing handlers or using embedded templating systems
like EmbPerl, Mason, or Template Toolkit.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts mod_perl
on 11/19/00 6:04 PM, Randal L. Schwartz at [EMAIL PROTECTED] uttered the following: Didier Can I assume that whenever mod_perl is enabled that all existing perl Didier scripts use it without any modification of any kind? Not at all. Apache::Registry is a good stop-gap, but you have to play by a number of useful and documented rules. When you're *really* good with mod_perl, you abandon Apache::Registry and move up to writing handlers or using embedded templating systems like EmbPerl, Mason, or Template Toolkit. At the moment, I'm just trying to get mod_perl to work and have users' scripts use it. I haven't had time to read docs on how to use it, only enough to get it going. Will it speed up regular scripts? Will it reduce the strain on system resources? Can I force existing scripts to use it with only a Files section? without modifying any scripts? How can I get confirmation that scripts are actually using it -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts mod_perl
When you're *really* good with mod_perl, you abandon Apache::Registry and move up to writing handlers or using embedded templating systems like EmbPerl, Mason, or Template Toolkit. Actually, if your using EMBPERL, why even BOTHER with the CGI interface at all. But I think that EMBPERL uses CGI.pm. I generally teach CGI for ten minutes and then jump straight into therorical Mod_perl and into Practical EMBPERL. Ruben http://www.mrbrklyn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts mod_perl
Find the time to READ the documentation Tonight would be a good nite. Ruben http://www.mrbrklyn.com At the moment, I'm just trying to get mod_perl to work and have users' scripts use it. I haven't had time to read docs on how to use it, only enough to get it going. Will it speed up regular scripts? Will it reduce the strain on system resources? Can I force existing scripts to use it with only a Files section? without modifying any scripts? How can I get confirmation that scripts are actually using it -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CGI scripts mod_perl
Quick (and maybe stupid) question(s): How do we make sure regular CGI scripts are using mod_perl??? Is there a way to find out? Is there anything to modify to make them work with mod_perl?? -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::Sandwich and CGI scripts
"HJE" == Hackett, Jonny E [EMAIL PROTECTED] writes: HJE I'm attempting to incorporate Apache::Sandwich into a site I'm working on HJE and I'm having some problems getting sandwich to work with cgi scripts. What shows up in your error logs? Did you read the section in the Apache::Sandwich docs about sandwiching mod_perl programs? If you are trying to sandwich plain old CGI's (which it doesn't seem like) then you can set SandwichHandler to cgi-handler and let it do the work. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Apache::Sandwich and CGI scripts
Hello, I'm attempting to incorporate Apache::Sandwich into a site I'm working on and I'm having some problems getting sandwich to work with cgi scripts. What is happening is that it will insert the header just fine, print the output, but it doesn't finish the final step which should insert the footer. And I've gone back and tried the hello world example in the documentation and get the same results. I've turned on debugging, and here's what shows up in the errorlog: inserting /mod_perl/cgi_wrapper.pl GET Use of uninitialized value in split at /usr/local/lib/perl5/site_perl/5.6.0/Apache/Sandwich.pm line 83. My httpd.conf has for following settings for the cgi-bin: Directory "/www/vhosts/localhost/cgi-bin" SetHandler perl-script PerlHandler Apache::Registry AllowOverride None Options +ExecCGI Order allow,deny Allow from all PerlSetVar HEADER "/mod_perl/cgi_wrapper.pl" PerlSetVar FOOTER "/wrapper/footer.html" /Directory It's currently running on RH6.2, apache1.3.14, mod_perl 1.24_01, Apache::Sandwich 2.04. If you have any insight as to what I'm doing wrong, I'd greatly appreciate knowing. Thanks, Jonny
RE: parsing SSI in cgi scripts?
Hi, Is there way for processing SSI commands in perl? (my templates may contains SSI commands, so what should I do - just type in real html or process them somehow?) Check out Apache::SSI. It can solve the problem. Can be used with Apache::Filter or by instantiating an Apache::SSI object directly. Ok! Thanks!
parsing SSI in cgi scripts?
Hi, Is there way for processing SSI commands in perl? (my templates may contains SSI commands, so what should I do - just type in real html or process them somehow?) /Vlad
RE: parsing SSI in cgi scripts?
check out Apache::Filter + Apache::SSI - both on CPAN --Geoff -Original Message- From: Vladislav Safronov [mailto:[EMAIL PROTECTED]] Sent: Friday, August 11, 2000 11:59 AM To: [EMAIL PROTECTED] Subject: parsing SSI in cgi scripts? Hi, Is there way for processing SSI commands in perl? (my templates may contains SSI commands, so what should I do - just type in real html or process them somehow?) /Vlad
Re: parsing SSI in cgi scripts?
[EMAIL PROTECTED] (Vladislav Safronov) wrote: Hi, Is there way for processing SSI commands in perl? (my templates may contains SSI commands, so what should I do - just type in real html or process them somehow?) Check out Apache::SSI. It can solve the problem. Can be used with Apache::Filter or by instantiating an Apache::SSI object directly.
Re: Overriding print in cgi scripts
Chetan Patil ([EMAIL PROTECTED]) said something to this effect: Hello, We have a large code base printing header, body and footers to the STDOUT from the cgi scripts. Since all these are print statements, we have to go to extreme measures to make sure we donot print the content more than once. To clean things up (or at least start at it), we want to be able to trap the output of print to a local buffer and then selectively flush or junk based on the logic (for eg, if we decide to redirect at the end of the script, then we want to junk the buffer). I am looking for a quick solution which would allow me to override the CORE::print function and simply write to a buffer (a perl scalar). Once I am done with the processing, I can write out the buffer or junk it. Is it possible to do this? What should I be careful of? How about selecting a different filehandle than STDOUT? For example, an IO::String object? IO::String is great (find it on CPAN). Here's an example: bash$ perl -MIO::String my $f = ''; my $io = IO::String-new($f); my $oldfh= select $io; print "Hello, World!\n"; select $oldfh; print $f; ^D Hello, World! bash$ Create a new IO::String object at the beginning of each script, select it, and then you don't have to modify your print statements. Just be sure to reselect STDOUT (or $oldfh as above). Beware, however: IO::String seems pretty expensive (it uses tie). (darren) -- There are worse things in life than death. Have you ever spent an evening with an insurance salesman? -- Woody Allen
Re: Overriding print in cgi scripts
On Sat, Jul 29, 2000 at 03:26:02PM -0700, Chetan Patil wrote: Hello, We have a large code base printing header, body and footers to the STDOUT from the cgi scripts. Since all these are print statements, we have to go to extreme measures to make sure we donot print the content more than once. To clean things up (or at least start at it), we want to be able to trap the output of print to a local buffer and then selectively flush or junk based on the logic (for eg, if we decide to redirect at the end of the script, then we want to junk the buffer). I am looking for a quick solution which would allow me to override the CORE::print function and simply write to a buffer (a perl scalar). Once I am done with the processing, I can write out the buffer or junk it. Is it possible to do this? What should I be careful of? Perhaps Apache::Filter do the job ? -- Y a n n K e r h e r v é| [EMAIL PROTECTED] Developer EdenJob, Webmaster Esiea-Ouest | ICQ: 43893215 Perl Mongueur, Linux, Linux-Alpha, ... | TEL: 0146217695
Overriding print in cgi scripts
Hello, We have a large code base printing header, body and footers to the STDOUT from the cgi scripts. Since all these are print statements, we have to go to extreme measures to make sure we donot print the content more than once. To clean things up (or at least start at it), we want to be able to trap the output of print to a local buffer and then selectively flush or junk based on the logic (for eg, if we decide to redirect at the end of the script, then we want to junk the buffer). I am looking for a quick solution which would allow me to override the CORE::print function and simply write to a buffer (a perl scalar). Once I am done with the processing, I can write out the buffer or junk it. Is it possible to do this? What should I be careful of? THanks, Chetan
Re: converting CGI scripts to mod_perl and memory use...
On Wed, 17 May 2000, Doug MacEachern wrote: On Wed, 17 May 2000, Dave DeMaagd wrote: I'm in the midst of converting a script I wrote in a CGI environment to mod_perl (using Apache::Registry). The scripts are running fine (after a little tweaking to get rid of globals and whatnot), but I am still looking for more ways to keep memory consumption under control, and for ways to check to see /where/ it's going out the window when it is. this message from last night was intended to remind of one way to do that.. Date: Tue, 16 May 2000 23:13:19 -0700 (PDT) From: Doug MacEachern [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [ANNOUNCE] B-Size-0.04 if you're not familar with B::Size, it was written a while back to answer the question 'why are my httpds so damn BIG?' there are hooks in Apache::Status to measure the size of global/lexical variables and the syntax tree. this is a debugging/educational module, for best results, run httpd in -X mode. and, do not enable on a production server, the code to measure the syntax tree can burn lots of cpu. And as usual the link: http://perl.apache.org/guide/performance.html#Measuring_the_Memory_Usage_of_Su _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
converting CGI scripts to mod_perl and memory use...
I'm in the midst of converting a script I wrote in a CGI environment to mod_perl (using Apache::Registry). The scripts are running fine (after a little tweaking to get rid of globals and whatnot), but I am still looking for more ways to keep memory consumption under control, and for ways to check to see /where/ it's going out the window when it is. Thanks! -- Dave DeMaagd - [EMAIL PROTECTED] - http://www.spinynorm.net I don't have a solution, but I admire your problem. SysAdmin/Programmer - TheImageGroup - ===|:=P
Re: converting CGI scripts to mod_perl and memory use...
On Wed, 17 May 2000, Dave DeMaagd wrote: I'm in the midst of converting a script I wrote in a CGI environment to mod_perl (using Apache::Registry). The scripts are running fine (after a little tweaking to get rid of globals and whatnot), but I am still looking for more ways to keep memory consumption under control, and for ways to check to see /where/ it's going out the window when it is. this message from last night was intended to remind of one way to do that.. Date: Tue, 16 May 2000 23:13:19 -0700 (PDT) From: Doug MacEachern [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [ANNOUNCE] B-Size-0.04 if you're not familar with B::Size, it was written a while back to answer the question 'why are my httpds so damn BIG?' there are hooks in Apache::Status to measure the size of global/lexical variables and the syntax tree. this is a debugging/educational module, for best results, run httpd in -X mode. and, do not enable on a production server, the code to measure the syntax tree can burn lots of cpu. ...
CGI scripts not executing.Re: works on linux, doesn't work on sun.
Actually, as I found out yesterday, it didn't fix it. I still just get the source. Further information. The symptoms were that I wasn't getting redirected properly. Yesterday some pieces finally came together which put me to the following point. Scripts are still not executing. The script that i was getting, was an error in the way i trapped the domain names. Ie, what I was getting, was one where the host was www rather then the fqdn. So this leaves me back at the origianl point, CGI scripts that are under the handler are not being ran. I've checked, and I do return DECLINED when my handler doesn't need to work with the content. Scott Doug MacEachern wrote: Location / SetHandler perl-script PerlSendHeader on PerlHandler Mf7 Options +ExecCGI strange that would fix things, unless your Mf7 module is testing for $r-allow_options OPT_EXECCGI mod_perl never checks that bit, it's up to modules, e.g. Apache::Registry make that check.
Re: CGI scripts not executing.Re: works on linux, doesn't work onsun.
On Tue, 16 May 2000 [EMAIL PROTECTED] wrote: Actually, as I found out yesterday, it didn't fix it. I still just get the source. Further information. The symptoms were that I wasn't getting redirected properly. Yesterday some pieces finally came together which put me to the following point. Scripts are still not executing. The script that i was getting, was an error in the way i trapped the domain names. Ie, what I was getting, was one where the host was www rather then the fqdn. So this leaves me back at the origianl point, CGI scripts that are under the handler are not being ran. I've checked, and I do return DECLINED when my handler doesn't need to work with the content. ok, you need to describe what Mf7 does. and what is supposed to handle things if you return DECLINED. when you say 'CGI scripts', do you mean Apache::Registry scripts? even you mean mod_cgi, i didn't see any config to handle either if you return DECLINED from Mf7.
