I know this off topic, but somewhat close. ;-)
Is there an easy way to use the param function in CGI.pm with mixed POST and GET data? I have some pages that use both (GET to the area, w/a form submision, for example) and it seems CGIs param will only get one type at a time.
It seems POST
"Michael L. Artz" <[EMAIL PROTECTED]> writes:
> For some reason, CGI.pm (2.93) does not seem to parse POST data within a
> PerlAuthenHandler. For example, the following:
>
> sub handler {
> my $r = shift;
> my $q = new CGI($r);
> my @params = $q
For some reason, CGI.pm (2.93) does not seem to parse POST data within a
PerlAuthenHandler. For example, the following:
sub handler {
my $r = shift;
my $q = new CGI($r);
my @params = $q->param;
$r->server->log->error("handler params are " . join "::"
> it helps when problem reports include information that helps to debug the
> problem. We can't possibly guess what setup you are using. In this case which
> CGI version are you using? CGI 2.93 works just fine with mp1 and mp2.
>
> CGI.pm does 'require Apache' on
Henrique Pantarotto wrote:
Henrique Pantarotto wrote:
I'm having some trouble with CGI.pm working with mod_perl2.
What trouble are you having?
logs/error_log reported this:
[Fri May 30 09:21:20 2003] [error] [client 10.29.31.104] Can't locate Apache.pm in @INC (@INC contains: /hom
> Henrique Pantarotto wrote:
> > I'm having some trouble with CGI.pm working with mod_perl2.
>
> What trouble are you having?
logs/error_log reported this:
[Fri May 30 09:21:20 2003] [error] [client 10.29.31.104] Can't locate Apache.pm in
@INC (@INC contains: /home
> > Option 3 seems okay, excect for the fact that I am that kind of Linux
> > user that is always upgrading everything to the latest version possible.
> > This applies to linux kernel, apache, etc. I don't really have a reason
> > to do this, but I have always done it anyway.
>
> You're nuts. I
Henrique Pantarotto wrote:
I'm having some trouble with CGI.pm working with mod_perl2.
What trouble are you having?
This guy clearly says
that CGI.pm is incompatible with mod_perl2:
http://marc.theaimsgroup.com/?l=apache-modperl&m=103619647305553&w=2
That was 7 months ago. A lo
Hi there,
On Tue, 3 Jun 2003, Henrique Pantarotto wrote:
> 3) downgrade apache to 1.3.27 and mod_perl to 1.27 and be happy
>
> Option 3 seems okay, excect for the fact that I am that kind of Linux
> user that is always upgrading everything to the latest version possible.
> This applies to linux
Hello!
after being a long time away (over 4 years since my last post on this
list), I started again with some development with mod_perl for this
company that I currently work for.
I'm having some trouble with CGI.pm working with mod_perl2. I searched
the mailing-list for this and I found
On Thu, May 29, 2003 at 04:12:51PM +1000, Stas Bekman wrote:
> Brown, Jeffrey wrote:
> >Problem solved!
> >
> >You all are a fantastic resource to newbies!
> >
> >Jeff
> >
> >-Original Message-
> >From: Ed [mailto:[EMAIL PROTECTED]
> >Sent: Wednesday, May 28, 2003 9:28 PM
> >To: Brown, Jef
Brown, Jeffrey wrote:
Problem solved!
You all are a fantastic resource to newbies!
Jeff
-Original Message-
From: Ed [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 9:28 PM
To: Brown, Jeffrey; [EMAIL PROTECTED]
On Wed, May 28, 2003 at 09:11:06PM -0700, Brown, Jeffrey wrote:
Her
Problem solved!
You all are a fantastic resource to newbies!
Jeff
-Original Message-
From: Ed [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 9:28 PM
To: Brown, Jeffrey; [EMAIL PROTECTED]
On Wed, May 28, 2003 at 09:11:06PM -0700, Brown, Jeffrey wrote:
> Here are the results fro
On Wed, May 28, 2003 at 09:11:06PM -0700, Brown, Jeffrey wrote:
> Here are the results from the log file:
>
> [Wed May 28 20:50:21 2003] [error] No such file or directory at
> /htdocs/perl/first.pl line 6 during global destruction.
openbsd's httpd is chrooted.
Ed.
nd was just this:
open(CGI, '/usr/libdata/perl5/CGI.pm') or die $!;
If you can't read the file, that line will die.
- Perrin
en(CGI, '/usr/libdata/perl5/CGI.pm') or die $!;
If you can't read the file, that line will die.
- Perrin
On Wed, 28 May 2003, Brown, Jeffrey wrote:
> Do you mean give the path in my perl script?
> So the line in my code:
> use CGI qw(:standard);
> would be:
> use /usr/libdata/perl5/CGI qw(:standard);
I think what Perrin had in mind was to try, in your CGI
script, something like
open(FILE, '
PROTECTED]
On Wed, 2003-05-28 at 22:39, Brown, Jeffrey wrote:
> [Wed May 28 19:33:57 2003] [error] Can't locate CGI.pm in @INC (@INC
> contains:
[...]
> /usr/libdata/perl5/CGI.pm
This sort of thing is usually a permissions problem. Try opening that
file (full path to CGI.pm) fro
On Wed, 2003-05-28 at 23:15, Brown, Jeffrey wrote:
> Here are the permissions on the file:
>
> -r--r--r-- 1 root wheel 224666 Apr 28 06:35 CGI.pm
>
> The BSD OS is new to me, I am more familure with redhat...but there are
> some definite perks to OpenBSD and that is why I ru
Here are the permissions on the file:
-r--r--r-- 1 root wheel 224666 Apr 28 06:35 CGI.pm
The BSD OS is new to me, I am more familure with redhat...but there are
some definite perks to OpenBSD and that is why I run it. Anyway wheel is
the group, and Apache uses the user and group www to run
ocate CGI.pm in @INC (@INC
contains: /usr/local/lib/site_perl/5.6.1/i386-openbsd
/usr/libdata/perl5/i386-openbsd/5.6.1
/usr/local/libdata/perl5/i386-openbsd/5.6.1 /usr/libdata/perl5
/usr/local/libdata/perl5 /usr/local/libdata/perl5/site_perl/i386-openbsd
/usr/libdata/perl5/site_perl/i386-openbsd
On Wed, 2003-05-28 at 22:39, Brown, Jeffrey wrote:
> [Wed May 28 19:33:57 2003] [error] Can't locate CGI.pm in @INC (@INC
> contains:
[...]
> /usr/libdata/perl5/CGI.pm
This sort of thing is usually a permissions problem. Try opening that
file (full path to CGI.pm) from your CGI
I have installed OpenBSD 3.2, with
Apache 1.3.26, and mod_perl 1.26 which was installed
as a package. I have rebooted, stopped and started apache. I have permissions
of 755 on my perl scripts and here is my error log:
[Wed May 28 19:33:57 2003] [error]
Can't locate CGI.pm in @INC
[EMAIL PROTECTED] wrote:
thnx for your reply.
I use mod_perl 2 (1.99_08) and CGI.pm 2.91 and Apache 2.0.44. I thought that CGI.pm
wouldnt work at all, so I didnt give any examples.
I wrote a simply script that checks if running under mod_perl,
displays some parameter and evaluates/presents a
thnx for your reply.
I use mod_perl 2 (1.99_08) and CGI.pm 2.91 and Apache 2.0.44. I thought that CGI.pm
wouldnt work at all, so I didnt give any examples.
I wrote a simply script that checks if running under mod_perl,
displays some parameter and evaluates/presents a form.
This script
Hi!
On Wed, Apr 02, 2003 at 12:49:56AM +0200, [EMAIL PROTECTED] wrote:
> Is the O'Reilly about apache-modules what I'm looking for ? I've the
> small O'reilly about mod_perl but it raises more questions than its
> answers.
The "Eagle" book is definitly very interesting (if a little bit old - B
[EMAIL PROTECTED] wrote:
I used CGI.pm in my mod_perl-application to get 'path_info', 'param',
print out headers and more.
None of this works inside my own handlers any more.
Which mod_perl generation are you using? mod_perl 1.0 (1.27?) or mod_perl 2.0
(1.99_08?). I susp
While I'm programming mod_perl for quite a while now I only recently
discovered the wonders of writing my own apache-handlers.
I used CGI.pm in my mod_perl-application to get 'path_info', 'param',
print out headers and more.
None of this works inside my own handler
On Tue, 25 Mar 2003, Stas Bekman wrote:
[...]
> > http://marc.theaimsgroup.com/?l=apache-modperl&m=95587404903236&w=2
>
> If something can be made faster with very little effort, why not doing that?
Often because the cost of having to deal with the increased
complexity and new obscure bugs isn't
W, my post was regarding mp1, since Apache::Request is available for mp1.
Once Apache::Request is available for mp2, it can be integrated as well.
Hopefully it's Perl API won't change, so CGI.pm will probably not need to be
changed as well.
Is Apache::Request in mp2 ready for prime ti
On Tue, 25 Mar 2003, Lincoln Stein wrote:
> I like the idea of that, although the handsprings needed to do ordinary CGI,
> mp1 and mp2 might lead to a cloud of confusion. Best to keep them in
> separate modules and load them into CGI as needed.
>
> Is Apache::Request in mp2 ready for prime time?
At least with some versions of perl, the require gets evaluated at compile
time and raises an exception even if it is enclosed by the eval {} braces.
The only way to get around this is to eval the string.
I'm not sure whether this is a current issue or was a problem with 5.00503,
but I've kept
e::UploadMeter) and response handlers like CGI scripts which use
> CGI.pm I suppose that this isn't such a big problem in mp2 whose filters
> will probably make using one API for request handling unnecessary...
>
> Issac
>
> - Original Message -
> From: "S
That would be really amazing if it could still be implemented in mp1, too,
as it would allow for interoperability between libapreq-based applications
(like Apache::UploadMeter) and response handlers like CGI scripts which use
CGI.pm I suppose that this isn't such a big problem in mp2
Gunther Birznieks wrote:
Stas Bekman wrote:
While we are at the CGI.pm issue, I was thinking that those who stick
with CGI.pm because of its extended all-in-one functionality (request
parsing/ HTML generation), but unhappy about request parsing speed,
could benefit by integrating Apache
Stas Bekman wrote:
While we are at the CGI.pm issue, I was thinking that those who stick
with CGI.pm because of its extended all-in-one functionality (request
parsing/ HTML generation), but unhappy about request parsing speed,
could benefit by integrating Apache::Request in CGI.pm to do the
While we are at the CGI.pm issue, I was thinking that those who stick with
CGI.pm because of its extended all-in-one functionality (request parsing/ HTML
generation), but unhappy about request parsing speed, could benefit by
integrating Apache::Request in CGI.pm to do the request parsing. So if
Lincoln Stein wrote:
Sorry for the slow turnaround, but it's an aspect of having 200 new e-mails
every day.
Here's a new version of CGI.pm 2.92 prerelease. Please give it a try on
mod_perl1 and mod_perl2 systems.
It passes all tests on linux. Hopefully others will test on other
note explaining why we don't rely on
$ENV{MOD_PERL}. I'm sure the reason will be forgotten in the future.
if (exists $ENV{MOD_PERL}) {
eval "require mod_perl";
# mod_perl handlers may run system() on scripts using CGI.pm
# - make sure so we don't get fooled by i
} else {
$MOD_PERL = 1;
require Apache;
}
}
}
Lincoln
On Thursday 13 March 2003 06:21 pm, Stas Bekman wrote:
> Lincoln Stein wrote:
> > Please find enclosed a beta version of CGI.pm 2.92. I would
Stas Bekman wrote:
Stas Bekman wrote:
Lincoln Stein wrote:
Please find enclosed a beta version of CGI.pm 2.92. I would
appreciate it if people could test it on both mod_perl 1 and mod_perl
2, as well as under normal CGI scripts too ;-)
Thanks Lincoln. 'make test' passes with m
Stas Bekman wrote:
Lincoln Stein wrote:
Please find enclosed a beta version of CGI.pm 2.92. I would
appreciate it if people could test it on both mod_perl 1 and mod_perl
2, as well as under normal CGI scripts too ;-)
Thanks Lincoln. 'make test' passes with mp1 and mp2
Ah, no it do
On Fri, Mar 14, 2003 at 10:31:25AM +1100, Carl Brewer wrote:
>
>
> Stas Bekman wrote:
> >Lincoln Stein wrote:
> >
>
> >You want to move to MP2, if one of the following reasons apply:
> >
> >- you are stuck with Apache2
> >- you want to use i/o filters
> >- you want to write your own protocol han
Stas Bekman wrote:
Lincoln Stein wrote:
You want to move to MP2, if one of the following reasons apply:
- you are stuck with Apache2
- you want to use i/o filters
- you want to write your own protocol handlers
- you want to use a threaded mod_perl
- you are stuck with win32 (mp1 is unusable on
Lincoln Stein wrote:
Please find enclosed a beta version of CGI.pm 2.92. I would appreciate it if
people could test it on both mod_perl 1 and mod_perl 2, as well as under
normal CGI scripts too ;-)
Thanks Lincoln. 'make test' passes with mp1 and mp2, however the test suites
aren'
Lincoln Stein wrote:
Hi Stas,
Thanks. I'll fold these changes and release on CPAN. I'll also remove the
$|=1 setting, since that was globally needed for FastCGI compatibility, and I
don't think that anyone uses it anymore.
Lincoln
They have came out with a fastcgi (mod_fastcgi-2.4.0) rele
oln,
>
> > I'm not interested in modifying CGI.pm to use MP2 until I start using MP2
> > myself. This isn't likely in the near future, since I'm very happy
> > indeed with MP1/Apache1.
>
> I've done the porting of CGI.pm, CGI::Carp and CGI::Pretty (no
Hi Lincoln,
I'm not interested in modifying CGI.pm to use MP2 until I start using MP2
myself. This isn't likely in the near future, since I'm very happy indeed
with MP1/Apache1.
I've done the porting of CGI.pm, CGI::Carp and CGI::Pretty (no more
Apache/compat.pm). I di
On Tue, 4 Mar 2003, Egor Korablev wrote:
> Hello.
>
> How can I get file upload from form using mod_perl 2 without CGI.pm?
>
> thx
You can't. At least not in an easy way, which I guess is what you want.
Apache::Request is not ported to mod_perl 2 yet. Time to fall back in lo
Hello.How can I get file upload from form using
mod_perl 2 without CGI.pm?thx
---
>
> and see that in error.log:
>
> [Tue Jan 14 13:59:08 2003] [error] Can't locate Apache.pm in @INC
[...]
> What I'm doing wrong? How to parse urlecnoded?
Does an upgrade of CGI.pm to the latest version help? Earlier
versions aren't mod_perl 2.0 aware
--
best regards,
randy kobes
[EMAIL PROTECTED] sent the following bits through the ether:
> What I'm doing wrong? How to parse urlecnoded?
Have you put the following into httpd.conf?:
PerlModule Apache2
Leon
--
Leon Brocard.http://www.astray.com/
scribot.http:/
/usr/local/apache2 /usr/local/lib/perl5/site_perl/5.8.0/i586-linux/Apache2
/usr/local/lib/perl5/5.8.0/i586-linux /usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/i586-linux /usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl .) at /usr/local/lib/perl5/5.8.0/CG
Jesse Erlbaum wrote:
Hi Coexec --
I am experienced with using the CGI.pm, and now I want
to rewrite all of my CGI's using mod_perl and
Apache::Request.
Maybe a silly question: What are you hoping to gain by doing this?
Speed. Apache::Request's guts are implemented in C, CGI.
Hi Coexec --
> I am experienced with using the CGI.pm, and now I want
> to rewrite all of my CGI's using mod_perl and
> Apache::Request.
Maybe a silly question: What are you hoping to gain by doing this?
If you're already using Apache::Registry, then your CGI.pm apps are
On Tue, 19 Nov 2002, Coexec wrote:
> Date: Tue, 19 Nov 2002 15:40:37 -0800 (PST)
> From: Coexec <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Migrating from CGI.pm to Apache::Request question.
>
> Hello all, I have been searching through the mailing
> list ar
Hello all, I have been searching through the mailing
list archives for the answer to my question, but I
have not found it.
I am experienced with using the CGI.pm, and now I want
to rewrite all of my CGI's using mod_perl and
Apache::Request. According to everything that I have
been reading
te object method "register_cleanup" via
> package
> > "Apache::RequestRec" at /usr/local/lib/perl5/5.8.0/CGI.pm line 270.
>
> this method is defined in Apache::compat. What happens if you add
>
> PerlModule Apache::compat
It works when I use this.
Thanks for your reply,
Phil.
as
explained here:
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
> Secondly, I get this error in the log when I try to
> run a CGI that uses CGI.pm:
>
> ModPerl::Registry: Can't locate object method "register_cleanup" via
package
> "Apache::Reques
other tests are fine. Secondly, I get this error in the log when I try to
run a CGI that uses CGI.pm:
ModPerl::Registry: Can't locate object method "register_cleanup" via package
"Apache::RequestRec" at /usr/local/lib/perl5/5.8.0/CGI.pm line 270.
The CGI in question works fin
On Fri, 2002-11-01 at 17:54, [EMAIL PROTECTED] wrote:
First, make sure you have the latest version of CGI.pm from CPAN. It has
fixes in there to automatically load Apache::Compat for you. Also CGI.pm
isn't fully mod_perl2 compatable. so there is that over head
unfortunally. Right now for me,
> If I use the Compat-mode the problem vanishes. Is
> the CGI-module
> incompatible with mod_perl2 ?
Yes !!
>If yes, is there any
> alternative that
> can be used without need to rewrite all our
> libraries that rely on
> CGI.pm ?
Probably not :-( unless you use Apache::comp
rl.so
PerlModule Apache2
and for my perl-files:
PerlResponseHandler ModPerl::Registry
As soon as I try to run a script under mod_perl that uses CGI.pm I get
the problem:
[Fri Nov 01 23:27:43 2002] [error] 9558: ModPerl::Registry: Can't locate Apache.pm in
@INC (@INC contains: /usr/local/lib/perl5
On Wed, 16 Oct 2002 [EMAIL PROTECTED] wrote:
> Hi,
>
> I have a problem when porting an application from Apache 1.23.x + mod_perl
> 1.0 to Apache 2.xx + mod_perl 2.0.
>
> One of the scripts receives as argument a filename (with no path info), and
> the scripts is suppose to open the file from t
Hi,
I have a problem when porting an application from Apache 1.23.x + mod_perl
1.0 to Apache 2.xx + mod_perl 2.0.
One of the scripts receives as argument a filename (with no path info), and
the scripts is suppose to open the file from the same directory in which
the script is located and perform
> From: mike808 [mailto:[EMAIL PROTECTED]]
> Sent: 24 July 2002 05:54
> To: Lincoln Stein; Cope, Greg; [EMAIL PROTECTED]
> Subject: Re: possible buget in CGI.pm
>
> Lincoln, Greg, mod_perl list:
>
> The problem appears to be that the -no_xhtml option is only
> pr
> On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote:
> > We do not want CGI.pm to return XHTML ...
> > So in Apache::Registry executed scripts we use:
> > use CGI qw( -no_xhtml );
> > But on the first invocation it returns normal HTML. On second inv
I'm aware of the problem, but I haven't been able to track it down. Any help
is welcome.
Lincoln
On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote:
> Hi All,
>
> We are implementing mod_perl here for internal intranet use. We have
> discovered a possible bugle
> -Original Message-
> From: darren chamberlain [mailto:[EMAIL PROTECTED]]
> > Can someone confirm this?
>
> Yes:
>
Good I'm not mad :-)
> From CGI.pm, version 2.81:
>
> 35 # >>>>> Here are some globals that you might want to
Hi,
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2002-07-23 11:26]:
> We are implementing mod_perl here for internal intranet use. We have
> discovered a possible buglet in CGI.pm.
>
> We do not want CGI.pm to return XHTML as it upsets Verity indexing
> (long story).
So sor
Hi All,
We are implementing mod_perl here for internal intranet use. We have
discovered a possible buglet in CGI.pm.
We do not want CGI.pm to return XHTML as it upsets Verity indexing (long
story).
So in Apache::Registry executed scripts we use:
use CGI qw( -no_xhtml );
But on the
Jeff wrote:
> I am gradually moving to mod_Perl using Apache::PerlRun instead of
> Apache::Registry. I am also considering switching from cgi-lib.pl to
> CGI.pm however I hear CGI.pm takes longer to load. Will CGI.pm
> automatically be cached, thereby eliminating the perform
Title: Message
I am gradually
moving to mod_Perl using Apache::PerlRun instead of Apache::Registry. I am
also considering switching from cgi-lib.pl to CGI.pm however I hear CGI.pm takes
longer to load. Will CGI.pm automatically be cached, thereby eliminating
the performance hit, by
ipt running on Apache
> 2.0.40-dev with mod-perl 1.99
any luck with ab from 2.0.40? I've just done some testing with CGI.pm
(it was printing the whole set of xml headers) and it seems to be fine
(with ab from 1.3 and 2.0). Care to send a *short* script
Greetings,
Tried to run some benchmarking tests on a cgi generated web page comparing a
light and heavy server.
ab worked fine when testing the script run by the Apache 2.0.39 light server
ab reported failure when testing the same script running on Apache
2.0.40-dev with mod-perl 1.99
Both work
Hi there,
On Wed, 20 Mar 2002, Vuillemot, Ward W wrote:
> > On Tue, 19 Mar 2002 14:06:15 -0800 Vuillemot, Ward W wrote:
> > > why would it work for cgi and not mod_perl?
> > >
> > From: Ged Haywood [Replying privately because of large attachment]
> > Does
> Keep in mind I tried several version of CGI.pm. Where the problem is
> (and yes, I did hack CGI.pm and fixed it but felt it was unnessary to
> hack CGI.pm since it wasn't at fault and didn't want to break other
> working apps), e, the problem is in the read_from_client
to all of those or even some (most importantly the threading bit).
Recompile without threading. and then try.
Keep in mind I tried several version of CGI.pm. Where the problem is
(and yes, I did hack CGI.pm and fixed it but felt it was unnessary to
hack CGI.pm since it wasn't at fault and d
uot;B::show()\n";
>}
>
>sub remove
>{
> print "B::remove()\n";
>}
>
> Inveriably, I end up with "B::show()" in my output, not at all what I wanted,
> expected or hoped for.
>
> What I see happening is that Apache::
Mike McLagan wrote:
> When B is invoked, within the same child, Apache::Registry DOES NOT reload
> CGI.pm and therefore does not initialize any of the variables, etc. This
> results in the new() call in B REUSING (!) the @QUERY_PARAM which was built up
> during the new() call
will not be run during
>>the response to an incoming request unless that request happens to be
>>the one that causes the compilation of the code.
>>
>
>Broken behavior, defined or not, is still broken behavior. Maybe it's
>up to the CGI.pm author to investigate what
blocks will not be run during
>the response to an incoming request unless that request happens to be
>the one that causes the compilation of the code.
Broken behavior, defined or not, is still broken behavior. Maybe it's
up to the CGI.pm author to investigate what he has to do to work
--
Programmer
http://www.arttoday.com/
http://www.rebelartist.com/
--
- Original Message -
From: "Mike McLagan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 07, 2002 10:59 AM
Subject: Weird mod_per
hat request happens to be
the one that causes the compilation of the code.
If you are having trouble coping with mod_perl and CGI.pm perhaps it
would better if you tried different approach, Apache::Request for
example has some useful features.
73,
Ged.
loading and query retrieval implies a number of things.
Specifically, based on the above referenced guide text, module CGI.pm is not
reloaded by the server from invocation to invocation. A good thing, for the
most part. The problem comes when a child server does not die between client
service
Hi again,
On Thu, 7 Feb 2002, Mike McLagan wrote:
> On Fri, 8 Feb 2002 01:18:19 + (GMT), Ged Haywood wrote:
>
> >On Thu, 7 Feb 2002, Mike McLagan wrote:
> >
> >> >Isn't this mentioned in the mod_perl Guide?
> >> >
> >> >http://perl.apache.org/guide
> >> >
> >>
> >> I dug thru the guide and
On Fri, 8 Feb 2002 01:18:19 + (GMT), Ged Haywood wrote:
>On Thu, 7 Feb 2002, Mike McLagan wrote:
>
>> >Isn't this mentioned in the mod_perl Guide?
>> >
>> >http://perl.apache.org/guide
>> >
>>
>> I dug thru the guide and I found no mention at all of anything
>> similar to this.
>
>http://per
Hi there,
On Thu, 7 Feb 2002, Mike McLagan wrote:
> >Isn't this mentioned in the mod_perl Guide?
> >
> >http://perl.apache.org/guide
> >
>
> I dug thru the guide and I found no mention at all of anything
> similar to this.
http://perl.apache.org/guide/porting.html
73,
Ged.
On Thu, 7 Feb 2002 18:38:53 + (GMT), Ged Haywood wrote:
>Hi there,
>
>On Thu, 7 Feb 2002, Mike McLagan wrote:
>
>>I have two scripts, call them A and B.
>[snip]
>>$q = new CGI;
>[snip]
>> Inveriably, I end up with "B::show()" in my output, not at all what I
wanted,
>
>Isn't this men
On Thu, 2002-02-07 at 13:38, Ged Haywood wrote:
> Hi there,
>
> On Thu, 7 Feb 2002, Mike McLagan wrote:
>
> >I have two scripts, call them A and B.
> [snip]
> >$q = new CGI;
> [snip]
> > Inveriably, I end up with "B::show()" in my output, not at all what I wanted,
>
> Isn't this mentio
Hi there,
On Thu, 7 Feb 2002, Mike McLagan wrote:
>I have two scripts, call them A and B.
[snip]
>$q = new CGI;
[snip]
> Inveriably, I end up with "B::show()" in my output, not at all what I wanted,
Isn't this mentioned in the mod_perl Guide?
http://perl.apache.org/guide
73,
Ged.
sub remove
{
print "B::remove()\n";
}
Inveriably, I end up with "B::show()" in my output, not at all what I wanted,
expected or hoped for.
What I see happening is that Apache::Registry is loading CGI.pm into the httpd
child the first time it encounters a script that
> I can't believe no-one else has run in to this. Something
> to do with the default instantiation of CGI is my guess.
It's actually highly unusual to do anything with CGI other than compile
it inside a BEGIN block. You may very well be the first person who
ever tried. Typical usage is to do i
Hi All,
Basically comes down to you cannot call the CGI.pm module in a
functional style within a block of code that is loaded at startup by a
mod-perl enabled web server.
Using CGI.pm in an OOP way eliminates the problem.
###
# this code causes
I'am migrating some scripts to run under Apache::Registry. The scripts are
programmed with the typical: use CGI qw/:standard/ ... and then recover the
parameter values wityh direct call to the function param("somefield").
This is happening with the last versions: apache:1.3.22 and mod_perl 1.
I'am migrating some scripts to run under Apache::Registry. The scripts are
programmed with the typical: use CGI qw/:standard/ ... and then recover the
parameter values wityh direct call to the function param("somefield").
This is happening with the last versions: apache:1.3.22 and mod_perl 1.2
On 6 Dec 2001, David Shrewsbury wrote:
> Solved it... apparently, if you upgrade CGI.pm while your web
> server is running, a restart is not good enough. You have to
> shutdown completely and then start it back up.
yeah, especially if you're using mod_perl and have pre-loaded mod
Solved it... apparently, if you upgrade CGI.pm while your web
server is running, a restart is not good enough. You have to
shutdown completely and then start it back up.
*Sigh*
-David
On Thu, 2001-12-06 at 10:43, David Shrewsbury wrote:
Hey gang,
I just upgraded the CGI.pm perl
Hey gang,
I just upgraded the CGI.pm perl module to 2.78 (don't know what the old
version was) and now none of my scripts running under Apache::Registry
are working. Instead of executing the scripts, I'm prompted to save the
script. Here is a sample script:
#!/usr/bin/perl
On Tue, 6 Nov 2001 15:52:20 -0500
Lincoln Stein <[EMAIL PROTECTED]> wrote:
> I'm amazed that CGI.pm does this, but you're right. What's bad is
> that this style doesn't work as expected:
>
> p $r->param(foo=>[qw(a b c)])
That's it! Any pl
1 - 100 of 279 matches
Mail list logo
