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
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 ::, @params);
return Apache::OK;
}
logs
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-param;
$r-server-log-error(handler params
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' only if it detects no mod_perl 2
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-modperlm=103619647305553w=2
That was 7 months ago. A lot has changed.
Keep
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'd fire
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
/usr/lib/perl5/site_perl/5.8.0
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: /home /usr/lib
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 many
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, Jeffrey; [EMAIL
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 (@INC
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 and see if it lets
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
/usr
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
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 run it. Anyway wheel
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) from your CGI and see
/libdata/perl5/CGI.pm')
or die Cannot read CGI.pm: $!;
This would test if the user under which the web
server is running under has permission to open CGI.pm.
--
best regards,
randy kobes
On Wed, 2003-05-28 at 23:25, 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);
Actually, what I had in mind was just this:
open(CGI, '/usr/libdata/perl5/CGI.pm
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.
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
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:
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
[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
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 handlers any more.
I discovered
[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 suspect that you use mp2
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 - BTW,
On Tue, 25 Mar 2003, Stas Bekman wrote:
[...]
http://marc.theaimsgroup.com/?l=apache-modperlm=95587404903236w=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 worth
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 whose
) 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: Stas Bekman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL
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
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? We
{
$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 appreciate
it if people could
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 inherited $ENV{MOD_PERL}
if (defined $mod_perl::VERSION
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 platforms
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
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
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
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 did some basic testing, however it'd be nice
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)
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't exhaustively
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
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 doesn't pass
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 mp1 and mp2
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 did some basic testing
Hello.How can I get file upload from form using
mod_perl 2 without CGI.pm?thx
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 love
with CGI.pm, just like
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
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.pm is Perl
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
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 archives for the answer to my question
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 ALREADY
running
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.
://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::RequestRec at /usr/local/lib/perl5/5.8.0/CGI.pm line 270.
this method
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 fine without mod_perl.
I'm using
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/site_perl
. 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::compat .
Checkout
http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache
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, I'll
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
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 the
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
processed in
_setup_symbols
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
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 sorry to hear about that.
So
-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
adjust
36 sub initialize_globals {
37 # Set
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 buglet in CGI.pm.
We do
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 invocation
it ignores this directive
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 handling
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 performance hit
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
-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 that
represents the problem
getc.pm pnotes.pm print.pm printf.pm readline.pm
sameinterp.pm
t/response/TestModules cgi.pm cgiupload.pm
Log:
tidy up tests:
- fetch/use Apache::OK instead of return 0;
- use() all modules used in tests even if preloaded elsewhere
- use warnings FATAL
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 the attached version of CGI.pm help? (I have added
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 didn't
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() call
where CGI.pm
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 around
this problem, but that's still a work around for 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 around
this problem, but that's still a work around for broken behavior.
If you are having trouble coping with mod_perl and CGI.pm perhaps it
would better if you tried different
is that Apache::Registry is loading CGI.pm into the httpd
child the first time it encounters a script that uses it. This runs a number
of functions within CGI.pm which set up variables, etc. The call to new() in A
then reads the query (GET or POST, doesn't matter) into @QUERY_PARAM.
When B
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
services on a busy server. Unless
unless that 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.
--
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_perl CGI.pm interaction (Bug
::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 uses it. This runs a number
of functions within CGI.pm which set up variables, etc. The call
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.
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 mentioned in the
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 mentioned in the
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 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.
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 I found no mention at all
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.26
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
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
use CGI qw
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
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 modules at
server
Hi,
Hopefully a quick and easy question...
I'm accessing as follows:
/cgi-bin/script.pl?data
And want to know how to get 'data' from somewhere using CGI.pm
Am familiar with using $cgi-param{'it'} to read .../script.pl?it=data
and also using $cgi-path_info() to read .../script.pl/data
but I
On Fri, 2 Nov 2001, James Wilson wrote:
Date: Fri, 2 Nov 2001 01:42:13 + (GMT)
From: James Wilson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: CGI.pm - Unnamed parameter
Hi,
Hopefully a quick and easy question...
I'm accessing as follows:
/cgi-bin/script.pl?data
And want
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)])
Lincoln
Tatsuhiko Miyagawa writes:
On Thu, 1 Nov 2001 09:58:39 -
Matt Sergeant [EMAIL PROTECTED] wrote:
I guess so. Your above
is equivalent to:
$r-param(foo = 'a', b = 'c');
(foo = qw(a b c)) doesn't do what it looks like it does,
and that's a bad
thing.
I know! but CGI.pm does it, so what I want is interface
consistency. CGI.pm also has a named parameter style which
Apache::Request doesn't
AM
To: James Wilson
Cc: [EMAIL PROTECTED]
Subject: Re: CGI.pm - Unnamed parameter
On Fri, 2 Nov 2001, James Wilson wrote:
Date: Fri, 2 Nov 2001 01:42:13 + (GMT)
From: James Wilson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: CGI.pm - Unnamed parameter
Hi,
Hopefully a quick
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 plan to fix this *strange* behaviour?
--
Tatsuhiko Miyagawa
-Original Message-
From: Tatsuhiko Miyagawa [mailto:[EMAIL PROTECTED]]
There is some inconsistency between CGI.pm and Apache::Request's
param() method, especially in handling of multivalued parameter.
$q = CGI-new;
$q-param(foo = qw(a b c));
@foo = $q-param('foo
There is some inconsistency between CGI.pm and Apache::Request's
param() method, especially in handling of multivalued parameter.
$q = CGI-new;
$q-param(foo = qw(a b c));
@foo = $q-param('foo'); # ('a', 'b', 'c')
$q-param(bar = [ qw(a b c) ]);
@bar = $q-param('bar
1 - 100 of 237 matches
Mail list logo
