Re: How to extract a parameter
Issac Goldstand wrote: Issac Goldstand wrote: Jonathan Vanasco wrote: On Jan 14, 2007, at 6:45 PM, Fred Moyer wrote: But it's really much easier to use CGI :) There's also libapreq OK - so out of the corner of my eye, I saw the link again as the previous mail was being copied to my sent-mail and noticed that it said RequestRec::args and not Request::args. So I put my foot in my mouth :-) As Jonathan correctly said, there's also libapreq: http://httpd.apache.org/apreq/docs/libapreq2/modules.html Boy, I'm on a roll this morning. The "previous email" ended up going to Jonathan only and not to the entire list. The important part of it [other than me incorrectly stating that http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_args_ was a link to libapreq :-)] was: I personally never liked using CGI with mod_perl; if I'm going through the trouble of writing optimized handlers to make my application that much faster, why use a pure-perl solution that needs to do full parsing in perl-land, when a lighter-weight C-based alternative is available that takes full advantage of Apache's internal I/O handling inside the server already? So it's a bit of a learning curve. So what? You learned mod_perl's ins and outs already - libapreq is significantly easier to grasp IMHO. I agree it's much more powerful, and it is my power tool of choice :) In the original context of the question though, the poster was asking how to grab the the query string arguments. In that situation where someone is not familiar with the basic operations of request parameter handling, I would recommend CGI because it's a lot easier to get the desired result quickly, which I think is important for someone learning modperl. CGI is installed on most systems, and while that extra speed from libapreq is nice, I've seen the libapreq install trip up beginners (and a few experts from time to time, including myself!). I'm working on a project right now where I'm optimizing some request handlers which use CGI under modperl. I'm using Apache::DProf to profile the handlers, and the request parameter handling calls under CGI are a significant component of the processing time (haven't profiled the memory distribution). I'm planning to use libapreq to speed up the handlers - I'll ask for permission to post the results. I know it will be a lot faster but it should be interesting to see the numbers.
Re: How to extract a parameter
Fred Moyer wrote:
>> Issac Goldstand wrote:
>> I personally never liked using CGI with mod_perl; if I'm going through
>> the trouble of writing optimized handlers to make my application that
>> much faster, why use a pure-perl solution that needs to do full parsing
>> in perl-land, when a lighter-weight C-based alternative is available
>> that takes full advantage of Apache's internal I/O handling inside the
>> server already?
>>
>> So it's a bit of a learning curve. So what? You learned mod_perl's ins
>> and outs already - libapreq is significantly easier to grasp IMHO.
>
> I agree it's much more powerful, and it is my power tool of choice :) In
> the original context of the question though, the poster was asking how
> to grab the the query string arguments. In that situation where someone
> is not familiar with the basic operations of request parameter handling,
> I would recommend CGI because it's a lot easier to get the desired
> result quickly, which I think is important for someone learning
> modperl. CGI is installed on most systems, and while that extra speed
> from libapreq is nice, I've seen the libapreq install trip up beginners
> (and a few experts from time to time, including myself!).
When libapreq2 was being developed, we realized that the learning curve
for the new interfaces (APR::Request::xxx) might be tricky for some
people to get the hang of (especially if they were used to the old
libapreq1 way of doing things), so Apache2::Request was added to make
things simple and as backwards-compatible as possible. How would you
envision it being simpler than it currently is?
Instead of doing:
my $q=CGI->new;
my $param=$q->param('foo');
One needs to do:
my $req=Apache2::Request->new($r);
my $param=$req->param('foo');
I still fail to see the difficulty... If someone can think of an even
simpler way, I'd be all for getting it included in future libapreq
releases...
Issac
Re: How to extract a parameter
On Jan 16, 2007, at 4:07 AM, Fred Moyer wrote: I agree it's much more powerful, and it is my power tool of choice :) In the original context of the question though, the poster was asking how to grab the the query string arguments. In that situation where someone is not familiar with the basic operations of request parameter handling, I would recommend CGI because it's a lot easier to get the desired result quickly, which I think is important for someone learning modperl. CGI is installed on most systems, and while that extra speed from libapreq is nice, I've seen the libapreq install trip up beginners (and a few experts from time to time, including myself!). I'm working on a project right now where I'm optimizing some request handlers which use CGI under modperl. I'm using Apache::DProf to profile the handlers, and the request parameter handling calls under CGI are a significant component of the processing time (haven't profiled the memory distribution). I'm planning to use libapreq to speed up the handlers - I'll ask for permission to post the results. I know it will be a lot faster but it should be interesting to see the numbers. As a rule of thumb , i believe in this: If you are developing code that will only run under mod_perl, use libapreq ( ie : using the handler + api functionality and not simple code caching ) If you are developing code that you may want to run in another environment , use CGI ( be it a standalone perl server, fcgi, etc ) In terms of numbers: http://modperlbook.org/html/ch13_02.html its old.. libapreq is probably a bit faster now. performance difference between the two is negligble for a handful of params, but CGI performace degrades signficantly faster than libapreq with each additional argument. i just use libapreq. i'd love to figure out a compatibility layer one day , and just be able to abstract all my code from mod_perl so it *could* run under fcgi or something if need be. i severely doubt that will ever happen, but it is a bit disconcerting to me at times that certain things I have are locked into Apache+mod_perl , and not just perl. Not that I want to switch, its just that not having the option to easily switch can lead to a little anxiety. // Jonathan Vanasco | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | FindMeOn.com - The cure for Multiple Web Personality Disorder | Web Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | RoadSound.com - Tools For Bands, Stuff For Fans | Collaborative Online Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http authentication via a secure LDAP server
I am running Apache 2.0.55 with mod_perl 2.0.1 and Perl 5.8.1 on a Sun Solaris machine. We would like to do http authentication via our ldap server which is installed with SSL. Are there perl modules that have to be installed or must I recompile apache and mod_perl with specific options? Can anyone point me in the right direction. Thanks for any information. Malka Cymbalista Webmaster, Weizmann Institute of Science [EMAIL PROTECTED] 08-934-3036
see the headers
Hi, I am using a reverse proxy (mod_proxy) and the server give a 400 error telling that the header doesn't contain a : character and shows the line GET / HTTP/1.1 Of course that line doesn't have a : char, but it shouldn't have one. I want to see what headers are sent by the proxy server to the backend server and I don't know how. I have found the perl module Apache::DumpHeaders but it works only with mod_perl1, and I am using mod_perl2. Do you know if there is a way of watching the headers sent between the proxy and the back-end server? Or even better, do you have any idea about how I could solve that problem? Thanks. Octavian
Re: http authentication via a secure LDAP server
On Tuesday 16 January 2007 05:35, Malka Cymbalista wrote: > I am running Apache 2.0.55 with mod_perl 2.0.1 and Perl 5.8.1 on a Sun > Solaris machine. We would like to do http authentication via our ldap > server which is installed with SSL. Are there perl modules that have to be > installed or must I recompile apache and mod_perl with specific options? > Can anyone point me in the right direction. Thanks for any information. Have you looked at: http://httpd.apache.org/docs/2.0/mod/mod_auth_ldap.html Sean
Re: How to extract a parameter
Issac Goldstand wrote: I still fail to see the difficulty... The difficulty that we most frequently see reported here is compiling Apache2::Request. People have trouble with it often enough to make it a consideration for beginners. - Perrin
Apache2::RequestUtil error
Hi folks, Not sure whether this issue has been resolved earlier, but did my bit searching on the list and googled - couldn't find any standard solutions working for me. And apologies for the long mail. I am upgrading our servers to mod_perl 2.0.2 and Apache 2.0.59 (compiled from source) We get the following errors for a few of our perl cgi scripts Usage: Apache2::Cookie->fetch($r): missing argument $r: attempt to fetch global Apache2::RequestUtil->request failed: Can't locate object method "request" via package "Apache2::RequestUtil" at /opt/apache-2.0.59/3plib/lib/perl5/site_perl/5.8.8/i686-linux/Apache2/Coo kie.pm line 32. . I have tried adding --- use Apache2; use Apache2::compat; --- in the startup.pl file but Apache can't find Apache2.pm and hence wouldn't start. If I just add in the Apache2::compat, it still shows the same above errors. Any pointers very much appreciated :) Thanks, Sunil Check out the new AOL. Most comprehensive set of free safety and security tools, free access to millions of high-quality videos from across the web, free AOL Mail and more.
Re: MP 2.0.3 & Apache 2.2.3 -> auth tests fail
> Back to 2.2.4 - MP2.0.3 worked with one alteration. It seems that > ap_get_server_version is not only depreciated, but also changed > functionality. That is... one test fails because it calls > get_server_version, expects "Apache 2.2.4 (Unix)" but gets "Apache > 2.2.4". ugh. I guess we haven't been paying attention. the relevant changes are these: Changes with Apache 2.2.4 *) The full server version information is now included in the error log at startup as well as server status reports, irrespective of the setting of the ServerTokens directive. ap_get_server_version() is now deprecated, and is replaced by ap_get_server_banner() and ap_get_server_description(). [Jeff Trawick] Changes with Apache 2.3.0 *) ap_get_server_version() has been removed. Third-party modules must now use ap_get_server_banner() or ap_get_server_description(). [Jeff Trawick] so we'll need to address these. fwiw, there are lots of changes in 2.2.0 and above that simplay haven't been incorporated into mod_perl yet, simply for lack of developer tuits. so, help/patches in this respect most welcome. come on and join [EMAIL PROTECTED] if you're interested :) > This can be solved by applying the following patch: > But note that this is not a backwards compatible patch. yeah, we can't bork back compat. but there is a way to maintain compat between moving APIs via modperl_apache_compat.c. right now that file is empty, but you can see what entries would look like by peeking at old versions in svn. I suspect what we'd want would be to hack the map to o add ap_get_server_banner and ap_get_server_description to the apache function map and mark them both as mod_perl implemented o add code to modperl_apache_compat.(c|h) to implement stubs for those routines if not currently defined, or callback to them if defined o mark ap_get_server_version as mod_perl implemented o add a stub for ap_get_server_version if not defined with a warning that the function is deprecated (else issue the callback) we did a similar workaround for something else, but I forget what it was. svn history will know, however. --Geoff
Re: How to extract a parameter
On 1/16/07, Issac Goldstand <[EMAIL PROTECTED]> wrote:
Instead of doing:
my $q=CGI->new;
my $param=$q->param('foo');
One needs to do:
my $req=Apache2::Request->new($r);
my $param=$req->param('foo');
I still fail to see the difficulty...
Agreed. It's not difficult to *use*, just a little interesting to
install in the first place. At least, it used to be. I know I had
some fun trying to get it to compile on Solaris a year or so back.
--
Kevin.
Re: Anyone using CGI::Simple?
Randal L. Schwartz wrote: "Andy" == Andy Armstrong <[EMAIL PROTECTED]> writes: Has anyone heard from James Freeman, the maintainer of CGI::Simple (http://search.cpan.org/dist/Cgi-Simple/)? It's not been updated in a couple of years, the outstanding bugs appear to mostly be related to the same issue, and I tried emailing him about this using the contact email he provided at http://www.perlmonks.org/?node=tachyon. Why would anyone use this instead of CGI.pm? I like it because: - uploads are handled more intuitively IMHO - no HTML stuff (although CGI's HTML methods are pretty slick) - no function/method oddness Not sure about its mod_perl issues, I use it mostly under persistent perl as anormal CGI...
Re: How to extract a parameter
- Original Message -
From: "Kevin Spencer" <[EMAIL PROTECTED]>
To: "Issac Goldstand" <[EMAIL PROTECTED]>
Cc: "Fred Moyer" <[EMAIL PROTECTED]>; "mod_perl list"
Sent: Tuesday, January 16, 2007 10:46 AM
Subject: Re: How to extract a parameter
> On 1/16/07, Issac Goldstand <[EMAIL PROTECTED]> wrote:
>
> > Instead of doing:
> > my $q=CGI->new;
> > my $param=$q->param('foo');
> >
> > One needs to do:
> > my $req=Apache2::Request->new($r);
> > my $param=$req->param('foo');
> >
> > I still fail to see the difficulty...
>
> Agreed. It's not difficult to *use*, just a little interesting to
> install in the first place. At least, it used to be. I know I had
> some fun trying to get it to compile on Solaris a year or so back.
>
> --
> Kevin.
I'm having fun with Solaris right now. The installation
is failing with no errors at all. I admit to not knowing
much about what I'm doing, but a *clue* at least would be
nice.
Giving up,
Jon
Re: Anyone using CGI::Simple?
On 16 Jan 2007, at 16:09, JupiterHost.Net wrote: Randal L. Schwartz wrote: "Andy" == Andy Armstrong <[EMAIL PROTECTED]> writes: Has anyone heard from James Freeman, the maintainer of CGI::Simple (http://search.cpan.org/dist/Cgi-Simple/)? It's not been updated in a couple of years, the outstanding bugs appear to mostly be related to the same issue, and I tried emailing him about this using the contact email he provided at http://www.perlmonks.org/?node=tachyon. Why would anyone use this instead of CGI.pm? I like it because: - uploads are handled more intuitively IMHO - no HTML stuff (although CGI's HTML methods are pretty slick) - no function/method oddness Not sure about its mod_perl issues, I use it mostly under persistent perl as anormal CGI... Splendid. Well the first release I've made is on CPAN now and I'm going to keep working on it to resolve the outstanding bugs and generally clean the code up. -- Andy Armstrong, hexten.net
Re: Anyone using CGI::Simple?
Why would anyone use this instead of CGI.pm? I like it because: - uploads are handled more intuitively IMHO - no HTML stuff (although CGI's HTML methods are pretty slick) - no function/method oddness Not sure about its mod_perl issues, I use it mostly under persistent perl as anormal CGI... Splendid. Well the first release I've made is on CPAN now and I'm going to keep working on it to resolve the outstanding bugs and generally clean the code up. Nice, looks like we're in good hands :) Thanks Andy
Re: Anyone using CGI::Simple?
Andy Armstrong wrote: Has anyone heard from James Freeman, the maintainer of CGI::Simple (http://search.cpan.org/dist/Cgi-Simple/)? It's not been updated in a couple of years, the outstanding bugs appear to mostly be related to the same issue, and I tried emailing him about this using the contact email he provided at http://www.perlmonks.org/?node=tachyon. Why would anyone use this instead of CGI.pm? I like it because: - uploads are handled more intuitively IMHO - no HTML stuff (although CGI's HTML methods are pretty slick) - no function/method oddness Not sure about its mod_perl issues, I use it mostly under persistent perl as anormal CGI... I use it too. In CGI::Application run under Registry. I had to make few changes for it to run under mp2 IIRC.
Re: Anyone using CGI::Simple?
On 16 Jan 2007, at 16:25, Jiří Pavlovský wrote: I use it too. In CGI::Application run under Registry. I had to make few changes for it to run under mp2 IIRC. Do you still have those changes? I'd be interested to see a diff against the released version if possible. -- Andy Armstrong, hexten.net
Re: Anyone using CGI::Simple?
Andy Armstrong wrote: On 16 Jan 2007, at 16:25, Jiří Pavlovský wrote: I use it too. In CGI::Application run under Registry. I had to make few changes for it to run under mp2 IIRC. Do you still have those changes? I'd be interested to see a diff against the released version if possible. Those were just Apache -> Apache2 renaming issues.
Re: Anyone using CGI::Simple?
On 16 Jan 2007, at 16:45, Jiří Pavlovský wrote: Do you still have those changes? I'd be interested to see a diff against the released version if possible. Those were just Apache -> Apache2 renaming issues. OK, I think I got all those, thanks. -- Andy Armstrong, hexten.net
Re: Making .pm files run.
I added these lines: use lib '/usr/home/httpd/domains/www.ehunter.com/ehunter_perl/Handlers'; PerlModule Recipes SetHandler perl-script PerlHandler Recipes Options +ExecCGI PerlSendHeader On allow from all Now im getting this error on the httpd-error.log file: Syntax error on line 691 of /usr/local/etc/apache/httpd.conf: Can't locate Image/Magick.pm in @INC (@INC contains: /usr/home/httpd/domains/www.ehunter.com/ehunter_perl/Handlers /usr/local/lib/perl5/5.8.8/BSDPAN /usr/local/lib/perl5/site_perl/5.8.8/mach /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl /usr/local/lib/perl5/5.8.8/mach /usr/local/lib/perl5/5.8.8 . /usr/local/ /usr/local/lib/perl) at /usr/home/httpd/domains/www.ehunter.com/ehunter_perl/Handlers/RecipeTool.pm line 6. BEGIN failed--compilation aborted at /usr/home/httpd/domains/www.ehunter.com/ehunter_perl/Handlers/RecipeTool.pm line 6. Compilation failed in require at /usr/home/httpd/domains/www.ehunter.com/ehunter_perl/Handlers/Recipes.pm line 6. BEGIN failed--compilation aborted at /usr/home/httpd/domains/www.ehunter.com/ehunter_perl/Handlers/Recipes.pm line 6. Compilation failed in require at (eval 9) line 3. -- View this message in context: http://www.nabble.com/Making-.pm-files-run.-tf3016257.html#a8394174 Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: Making .pm files run.
On Tuesday 16 January 2007 12:03, iNetForce wrote: > Now im getting this error on the httpd-error.log file: > > Syntax error on line 691 of /usr/local/etc/apache/httpd.conf: > Can't locate Image/Magick.pm in @INC Looks like your code depends on Image::Magick. You will probably need to install it. It is available on CPAN. Sean
Re: How to extract a parameter
On Tue, 16 Jan 2007, Jonathan Vanasco wrote: [ ... ] i just use libapreq. i'd love to figure out a compatibility layer one day , and just be able to abstract all my code from mod_perl so it *could* run under fcgi or something if need be. i severely doubt that will ever happen, but it is a bit disconcerting to me at times that certain things I have are locked into Apache+mod_perl , and not just perl. Not that I want to switch, its just that not having the option to easily switch can lead to a little anxiety. Although mod_perl is a prerequisite for libapreq2, enough of the mod_perl APR::* modules can be used outside of a mod_perl environment so at to make it possible to use libapreq2 in, eg, a CGI environment. See the cgi.t test under glue/perl/t/apreq/ in the libapreq2 sources for an example. -- best regards, Randy Kobes
Re: Port/Sheme information
Tracy12 wrote: How can we retrieve the URL Scheme (http/https ?) from a perl module, Port given that only input parameter is $r should we use my $uri = Apache::URI->parse($r) and $uri->scheme; I use $r->get_server_port. If it's 80 it's http, if it's 443, it's https. Of course, this breaks if you run them on different ports. Rob
Re: Port/Sheme information
Robert Landrum <[EMAIL PROTECTED]> wrote: > Tracy12 wrote: > >How can we retrieve the URL Scheme (http/https ?) from a perl module, Port > >given that only input parameter is $r > > > >should we use my $uri = Apache::URI->parse($r) and $uri->scheme; > I use $r->get_server_port. If it's 80 it's http, if it's 443, it's > https. Of course, this breaks if you run them on different ports. If you're running under mod_ssl, you get a lot of extra environment variables, including a simple flag; the presence of the "HTTPS" environment variable means SSL is enabled. http://httpd.apache.org/docs/2.2/mod/mod_ssl.html Cheers, Tyler
Re: How to extract a parameter
On Tue, 16 Jan 2007 05:13:55 -0500 Jonathan Vanasco <[EMAIL PROTECTED]> wrote: > i just use libapreq. i'd love to figure out a compatibility layer > one day , and just be able to abstract all my code from mod_perl so > it *could* run under fcgi or something if need be. i severely doubt > that will ever happen, but it is a bit disconcerting to me at times > that certain things I have are locked into Apache+mod_perl , and > not just perl. Not that I want to switch, its just that not having > the option to easily switch can lead to a little anxiety. I believe most of the web frameworks provide this sort of abstraction, at least I know Gantry ( www.usegantry.org ) does. You can move between the Gantry standalone server, CGI, FCGI, MP1, and MP2 with little to no code changes. ( With the CGI interfaces you have to write a bit of code to handle URI location to handler mappings that you would normally get from httpd.conf ). - Frank Wiles <[EMAIL PROTECTED]> http://www.wiles.org -
Re: Making .pm files run.
I installed Image Magick, but now im getting this error: http# apachectl restart /usr/local/sbin/apachectl restart: httpd not running, trying to start Syntax error on line 691 of /usr/local/etc/apache/httpd.conf: Can't locate Mail/Sendmail.pm in @INC (@INC contains: /usr/home/httpd/domains/ww w.ehunter.com/ehunter_perl/Handlers /usr/local/lib/perl5/5.8.8/BSDPAN /usr/local /lib/perl5/site_perl/5.8.8/mach /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/ lib/perl5/site_perl /usr/local/lib/perl5/5.8.8/mach /usr/local/lib/perl5/5.8.8 . /usr/local/ /usr/local/lib/perl) at /usr/home/httpd/domains/www.ehunter.com/ehu nter_perl/Handlers/RecipeEmailTool.pm line 6. BEGIN failed--compilation aborted at /usr/home/httpd/domains/www.ehunter.com/ehu nter_perl/Handlers/RecipeEmailTool.pm line 6. Compilation failed in require at /usr/home/httpd/domains/www.ehunter.com/ehunter _perl/Handlers/Recipes.pm line 9. BEGIN failed--compilation aborted at /usr/home/httpd/domains/www.ehunter.com/ehu nter_perl/Handlers/Recipes.pm line 9. Compilation failed in require at (eval 9) line 3. I'm sorry if im bothering you guys, I just want to make this work. Thanks in advance. Sean Davis-3 wrote: > > On Tuesday 16 January 2007 12:03, iNetForce wrote: > >> Now im getting this error on the httpd-error.log file: >> >> Syntax error on line 691 of /usr/local/etc/apache/httpd.conf: >> Can't locate Image/Magick.pm in @INC > > Looks like your code depends on Image::Magick. You will probably need to > install it. It is available on CPAN. > > Sean > > -- View this message in context: http://www.nabble.com/Making-.pm-files-run.-tf3016257.html#a8396625 Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: Making .pm files run.
iNetForce wrote: > I installed Image Magick, but now im getting this error: > > http# apachectl restart > /usr/local/sbin/apachectl restart: httpd not running, trying to start > Syntax error on line 691 of /usr/local/etc/apache/httpd.conf: > Can't locate Mail/Sendmail.pm in @INC (@INC contains: Now it's looking for Mail::Sendmail which will need to be installed as well. It's quite possible that there are many more of these which need to be installed. So you can just keep installing them. To translate the file path name into a Perl module name you basically change all '/' into '::' and then drop the final '.pm'. -- Michael Peters Developer Plus Three, LP
Re: Problem with libapreq2 and make
> > false cru .libs/libapreq2.a util.o version.o cookie.o param.o parser.o > > parser_urlencoded.o parser_header.o parser_multipart.o module.o > > module_custom.o module_cgi.o error.o > > A pretty big clue. Included libtool configured with: AR="false" --Jon
Re: Making .pm files run.
You got me lost there, the terminology you guys use really throw me off, sorry :( sendmail is installed on the system, what exactly do I need to do so I dont get the sendmail error? Michael Peters wrote: > > > > iNetForce wrote: >> I installed Image Magick, but now im getting this error: >> >> http# apachectl restart >> /usr/local/sbin/apachectl restart: httpd not running, trying to start >> Syntax error on line 691 of /usr/local/etc/apache/httpd.conf: >> Can't locate Mail/Sendmail.pm in @INC (@INC contains: > > Now it's looking for Mail::Sendmail which will need to be installed as > well. > It's quite possible that there are many more of these which need to be > installed. So you can just keep installing them. To translate the file > path name > into a Perl module name you basically change all '/' into '::' and then > drop the > final '.pm'. > > -- > Michael Peters > Developer > Plus Three, LP > > > -- View this message in context: http://www.nabble.com/Making-.pm-files-run.-tf3016257.html#a8397895 Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: Making .pm files run.
iNetForce wrote: > You got me lost there, the terminology you guys use really throw me off, > sorry :( > sendmail is installed on the system, what exactly do I need to do so I dont > get the sendmail error? It's not sendmail, it's the Perl module named Mail::Sendmail (which acts a kind of a wrapper around sendmail). Almost all Perl modules are found on CPAN (http://search.cpan.org/) and can be installed via the CPAN shell. I assumed you installed Image::Magick that way, but you probably just installed it from source the image-magick source. On some systems the cpan shell can simply be accessed by the command 'cpan'. If that doesn't work, then you can do the same thing via this command: perl -MCPAN -e shell Since it's probably the first time it's been run on that box you'll need to configure it. After your done with the configuration you can then install stuff: cpan> install Mail::Sendmail That should get it installed for you. -- Michael Peters Developer Plus Three, LP
Re: Making .pm files run.
On Tuesday 16 January 2007 15:12, iNetForce wrote: > You got me lost there, the terminology you guys use really throw me off, > sorry :( > sendmail is installed on the system, what exactly do I need to do so I dont > get the sendmail error? Things that end in .pm are usually perl modules. So, you will need to install ALL the perl modules that are needed, perhaps one-at-a-time. CPAN (http://search.cpan.org) is the place to look. I don't know if you have a local perl user, but it sounds like it might be a good idea to touch base with him/her if these instructions aren't making much sense. Hope that helps. Sean > Michael Peters wrote: > > iNetForce wrote: > >> I installed Image Magick, but now im getting this error: > >> > >> http# apachectl restart > >> /usr/local/sbin/apachectl restart: httpd not running, trying to start > >> Syntax error on line 691 of /usr/local/etc/apache/httpd.conf: > >> Can't locate Mail/Sendmail.pm in @INC (@INC contains: > > > > Now it's looking for Mail::Sendmail which will need to be installed as > > well. > > It's quite possible that there are many more of these which need to be > > installed. So you can just keep installing them. To translate the file > > path name > > into a Perl module name you basically change all '/' into '::' and then > > drop the > > final '.pm'. > > > > -- > > Michael Peters > > Developer > > Plus Three, LP
Re: How to extract a parameter
On Jan 16, 2007, at 12:41 PM, Frank Wiles wrote: I believe most of the web frameworks provide this sort of abstraction, at least I know Gantry ( www.usegantry.org ) does. You can move between the Gantry standalone server, CGI, FCGI, MP1, and MP2 with little to no code changes. ( With the CGI interfaces you have to write a bit of code to handle URI location to handler mappings that you would normally get from httpd.conf ). well: 1) the abstraction is usually done within the framework. I haven't seen a general CPAN module yet that can be used outside of these frameworks. 2) I use my own MVC framework ( nothing met my needs a few years back ) // Jonathan Vanasco | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | FindMeOn.com - The cure for Multiple Web Personality Disorder | Web Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | RoadSound.com - Tools For Bands, Stuff For Fans | Collaborative Online Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: Apache2::RequestUtil error
On Tue, 16 Jan 2007, [EMAIL PROTECTED] wrote: Hi folks, Not sure whether this issue has been resolved earlier, but did my bit searching on the list and googled - couldn't find any standard solutions working for me. And apologies for the long mail. I am upgrading our servers to mod_perl 2.0.2 and Apache 2.0.59 (compiled from source) We get the following errors for a few of our perl cgi scripts Usage: Apache2::Cookie->fetch($r): missing argument $r: attempt to fetch global Apache2::RequestUtil->request failed: Can't locate object method "request" via package "Apache2::RequestUtil" at /opt/apache-2.0.59/3plib/lib/perl5/site_perl/5.8.8/i686-linux/Apache2/Coo kie.pm line 32. . Are you passing $r into fetch()? eg, my %cookies = Apache2::Cookie->fetch($r); I have tried adding --- use Apache2; use Apache2::compat; --- in the startup.pl file but Apache can't find Apache2.pm and hence wouldn't start. If I just add in the Apache2::compat, it still shows the same above errors. Apache2.pm is no longer present in mod_perl; see http://perl.apache.org/docs/2.0/rename.html -- best regards, Randy Kobes
Re: Port/Sheme information
Does this mean there is no direct way to retrieve the scheme from the $r I have seen old code bases where they do the following my $uri->Apache::URI->parse($r); my $schme= $uri->scheme; But this is not working in mod_perl2.x Robert Landrum wrote: > > Tracy12 wrote: >> How can we retrieve the URL Scheme (http/https ?) from a perl module, >> Port >> given that only input parameter is $r >> >> should we use my $uri = Apache::URI->parse($r) and $uri->scheme; >> > > I use $r->get_server_port. If it's 80 it's http, if it's 443, it's > https. Of course, this breaks if you run them on different ports. > > Rob > > -- View this message in context: http://www.nabble.com/Port-Sheme-information-tf3018818.html#a8401666 Sent from the mod_perl - General mailing list archive at Nabble.com.
Redirects?
I have a strange issue with a particular script that sometimes (often)
generates a 302 to another script without a clear reason why.
Oddly enough, I simply placed a few "warn('blah')" code snippets to crudely
determine from the error log where it was happening in production (because I
cannot replicate the issue in development (linux client/local server)) but
with the Warn() statements, if seems to no longer happen !! -- any
suggestions/clues where I might look? This is the only script that does
this under the same location/configuration.
Thank you for a tiny piece of your sanity
-W
Re: Port/Sheme information
Tracy12 wrote: > Does this mean there is no direct way to retrieve the scheme from the $r > > I have seen old code bases where they do the following > > my $uri->Apache::URI->parse($r); > my $schme= $uri->scheme; > > But this is not working in mod_perl2.x see http://perl.apache.org/docs/2.0/api/Apache2/URI.html and http://perl.apache.org/docs/2.0/api/APR/URI.html the equivalent mp2 code is something like this: my $uri = APR::URI->parse($r->pool, Apache2::URI->construct_url); my $scheme = $uri->scheme(); but I didn't test it so you might have to tweak it a bit. HTH --Geoff
Re: Apache2::RequestUtil error
On 17/01/07, Randy Kobes <[EMAIL PROTECTED]> wrote: On Tue, 16 Jan 2007, [EMAIL PROTECTED] wrote: > Hi folks, > > Not sure whether this issue has been resolved earlier, but did my bit > searching on the list and googled - couldn't find any standard solutions > working for me. And apologies for the long mail. > > I am upgrading our servers to mod_perl 2.0.2 and Apache 2.0.59 (compiled from > source) > > We get the following errors for a few of our perl cgi scripts > > Usage: Apache2::Cookie->fetch($r): missing argument $r: attempt to fetch > global Apache2::RequestUtil->request failed: Can't locate object method > "request" via package "Apache2::RequestUtil" at > /opt/apache-2.0.59/3plib/lib/perl5/site_perl/5.8.8/i686-linux/Apache2/Coo > kie.pm line 32. > . Are you passing $r into fetch()? eg, my %cookies = Apache2::Cookie->fetch($r); I'd guess this is the issue, since according to the docs Apache1 is my $cookies = Apache::Cookie->fetch; Apache2 is my $cookies = Apache2::Cookie->fetch($r); my %cookies = Apache2::Cookie->fetch($r); and the error is thrown only when $r is not defined. > I have tried adding > --- > use Apache2; > use Apache2::compat; > --- > in the startup.pl file but Apache can't find Apache2.pm and hence wouldn't > start. If I just add in the Apache2::compat, it still shows the same above > errors. Apache2.pm is no longer present in mod_perl; see http://perl.apache.org/docs/2.0/rename.html -- best regards, Randy Kobes -- Website: http://philw.co.uk Skype: philwhelan76 Email : [EMAIL PROTECTED] MSN Messenger : [EMAIL PROTECTED] iChat: [EMAIL PROTECTED]
Re: Apache2::RequestUtil error
On Tue, 16 Jan 2007, [EMAIL PROTECTED] wrote: > Hi folks, > > Not sure whether this issue has been resolved earlier, but did my bit > searching on the list and googled - couldn't find any standard solutions > working for me. And apologies for the long mail. > > I am upgrading our servers to mod_perl 2.0.2 and Apache 2.0.59 (compiled from > source) > > We get the following errors for a few of our perl cgi scripts > > Usage: Apache2::Cookie->fetch($r): missing argument $r: attempt to fetch > global Apache2::RequestUtil->request failed: Can't locate object method > "request" via package "Apache2::RequestUtil" at > /opt/apache-2.0.59/3plib/lib/perl5/site_perl/5.8.8/i686-linux/Apache2/Coo > kie.pm line 32. > . Are you passing $r into fetch()? eg, my %cookies = Apache2::Cookie->fetch($r); > I have tried adding > --- > use Apache2; > use Apache2::compat; > --- > in the startup.pl file but Apache can't find Apache2.pm and hence wouldn't > start. If I just add in the Apache2::compat, it still shows the same above > errors. Apache2.pm is no longer present in mod_perl; see http://perl.apache.org/docs/2.0/rename.html - Thanks Randy, we are trying to use the older scripts without any modifications. We use CGI, and get_session to read up the cookies. We want to get the page working without any issues and hence started using Apache2::compat. -- Regards, Sunil Check out the new AOL. Most comprehensive set of free safety and security tools, free access to millions of high-quality videos from across the web, free AOL Mail and more.
Re: Making .pm files run.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Jan 16, 2007 at 11:06:54AM -0800, iNetForce wrote: > > I installed Image Magick, but now im getting this error: Hi, Force just to repeat what has been said elsewhere in slightly different terms when you see this: > http# apachectl restart > /usr/local/sbin/apachectl restart: httpd not running, trying to start > Syntax error on line 691 of /usr/local/etc/apache/httpd.conf: > Can't locate Mail/Sendmail.pm that means that Perl is looking for a module Mail::Sendmail, which it expects to be in one file Mail/Sendmail.pm. It is looking in the following directories (I edited for clarity): > in @INC (@INC contains: > /usr/home/httpd/domains/www.ehunter.com/ehunter_perl/Handlers > /usr/local/lib/perl5/5.8.8/BSDPAN > /usr/local/lib/perl5/site_perl/5.8.8/mach > /usr/local/lib/perl5/site_perl/5.8.8 > /usr/local/lib/perl5/site_perl > /usr/local/lib/perl5/5.8.8/mach > /usr/local/lib/perl5/5.8.8 > . > /usr/local/ /usr/local/lib/perl) at So to remedy this, you can go to CPAN and install the missing module (which will probably go to /usr/local/lib/perl5 or ...site_perl). You might try to use the "standard" Perl modules in your OS (if there are any), but guessing from the paths in your @INC it looks like a homegrown Perl installation (the "local" bit). So CPAN looks like the better approach. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFrc6jBcgs9XrR2kYRApg9AJ9Q527Wc6gM6ImVKEM3OyUj4YsD6QCaApJR cB58h8/+7tXijWz/YCiSBiE= =29h/ -END PGP SIGNATURE-
Re: Redirects?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jan 16, 2007 at 04:45:10PM -0800, Will Fould wrote:
> I have a strange issue with a particular script that sometimes (often)
> generates a 302 to another script without a clear reason why.
>
> Oddly enough, I simply placed a few "warn('blah')" [...] [it] seems to no
> longer happen !!
Heh. Tough riddle, if you tell us so little ;-)
A timing dependency, aka race condition comes first to mind. Then it
might be as well some undefined variable which gets somehow straightened
on issuing the warn. Or small little green gremlins which run away in
horror when they hear the log files churning.
How does the redirect get generated in the script? I mean: at which
places does the script generate the 302 response and where does it come
from? (you might instrument those places to log a stack dump to shed
some light on the issue).
Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFrdCIBcgs9XrR2kYRAnMaAJ0csiMgyXKDwd+RwuoUwcIxxFOTZQCfcMSz
pKo4+71MJ4jYjsOk/BLU+JA=
=hFej
-END PGP SIGNATURE-
