Perl incompat. with apache/mod_perl upgrade
When I upgraded from
Solaris Apache/1.3.14 (Unix) mod_perl/1.24_01
to
Solaris Apache/1.3.17 (Unix) mod_perl/1.25
the following code in my debugging httpd.conf broke:
Perl
sub WWW_DIR () { $ENV{'HOME'} . '/www' ; } # this sub will persist to next
Perl
... more code, using WWW_DIR sometimes
/Perl
.. more plain apache conf stuff here
Perl
$AxCacheDir = WWW_DIR . '/htdocs/x/cache';
/Perl
While this worked before, it now generates an undef sub called at the second
Perl
section. Redefining it there again works, but emits strange prototype
mismatch stuff
at the 2nd Perl calling of the routine.
To restore the old behavior I had to define it again without the brackets
(the args
prototype) at the 2nd section.
Was this change intentionally done (why?!), or is it a by-product of some
other code advances?
What is the correct way of passing Perl stuff from one Perl section to
another?
Vassilii
Re: Perl incompat. with apache/mod_perl upgrade
On Mon, 12 Mar 2001, Khachaturov, Vassilii wrote:
When I upgraded from
Solaris Apache/1.3.14 (Unix) mod_perl/1.24_01
to
Solaris Apache/1.3.17 (Unix) mod_perl/1.25
the following code in my debugging httpd.conf broke:
Perl
sub WWW_DIR () { $ENV{'HOME'} . '/www' ; } # this sub will persist to next
Perl
... more code, using WWW_DIR sometimes
/Perl
.. more plain apache conf stuff here
Perl
$AxCacheDir = WWW_DIR . '/htdocs/x/cache';
/Perl
While this worked before, it now generates an undef sub called at the second
Perl
section. Redefining it there again works, but emits strange prototype
mismatch stuff
at the 2nd Perl calling of the routine.
To restore the old behavior I had to define it again without the brackets
(the args
prototype) at the 2nd section.
Was this change intentionally done (why?!), or is it a by-product of some
other code advances?
What is the correct way of passing Perl stuff from one Perl section to
another?
Please read
http://perl.apache.org/guide/config.html#Apache_Configuration_in_Perl
and you will understand how CPerl sections work.
I also don't understand why are you trying to use sub to define a
variable, which is pretty useless, since you use it only during
configuration. Also use the constant pragma.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: Perl incompat. with apache/mod_perl upgrade
Read it. It still doesn't address my questions
- why this stopped working with
the new mod_perl+apache. From the docs, rather, I'd expect a
routine or a variable defined in one Perl section persist to the other.
While I can't use global vars (they try to get tied to the non-existing
config. params), and lexicals remain scoped within the same Perl
section, I had to use a sub before, which I was able to access in
the other Perl section. Now I am not. The docs say, however, I
am eval-ed in Apache::ReadConfig - o.k., so the subs should get
defined there and then remain there, as long as the same config
file is read?
I didn't want to use too heavy stuff (PerlSetVar or the module recently
discussed here - was it Apache::Storage?)
because I just wanted some shortcuts for the scope of the .conf file
only. It was better to cut-n-paste them in the worst case than carve
them in Apache brains, stealing the precious memory
from mod_perl :-).
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 12, 2001 8:39 PM
To: Khachaturov, Vassilii
Cc: '[EMAIL PROTECTED]'
Subject: Re: Perl incompat. with apache/mod_perl upgrade
...
Perl
sub WWW_DIR () { $ENV{'HOME'} . '/www' ; } # this sub will persist to next
Perl
... more code, using WWW_DIR sometimes
/Perl
.. more plain apache conf stuff here
Perl
$AxCacheDir = WWW_DIR . '/htdocs/x/cache';
/Perl
While this worked before, it now generates an undef sub called at the
second
...
Was this change intentionally done (why?!), or is it a by-product of some
other code advances?
What is the correct way of passing Perl stuff from one Perl section to
another?
Please read
http://perl.apache.org/guide/config.html#Apache_Configuration_in_Perl
and you will understand how CPerl sections work.
I also don't understand why are you trying to use sub to define a
variable, which is pretty useless, since you use it only during
configuration. Also use the constant pragma.
RE: Perl incompat. with apache/mod_perl upgrade
On Mon, 12 Mar 2001, Khachaturov, Vassilii wrote:
Read it. It still doesn't address my questions
- why this stopped working with
the new mod_perl+apache. From the docs, rather, I'd expect a
routine or a variable defined in one Perl section persist to the other.
While I can't use global vars (they try to get tied to the non-existing
config. params), and lexicals remain scoped within the same Perl
section, I had to use a sub before, which I was able to access in
the other Perl section. Now I am not. The docs say, however, I
am eval-ed in Apache::ReadConfig - o.k., so the subs should get
defined there and then remain there, as long as the same config
file is read?
Perl
$Apache::Config::foo = "bar";
/Perl
Perl
warn "\$foo = $Apache::Config::foo";
/Perl
prints:
$foo = bar at /
since there is no strict imposed, this does as well:
Perl
$foo = "bar";
/Perl
Perl
warn "\$foo = $foo";
/Perl
This works too:
Perl
use constant FOO = "bar";
/Perl
Perl
warn "\$foo = ".FOO;
/Perl
And indeed this doesn't work:
Perl
sub FOO {"bar"};
/Perl
Perl
warn "\$foo = ".FOO();
/Perl
We need to look at the code to see why subs get scoped like lexicals.
I didn't want to use too heavy stuff (PerlSetVar or the module recently
discussed here - was it Apache::Storage?)
because I just wanted some shortcuts for the scope of the .conf file
only. It was better to cut-n-paste them in the worst case than carve
them in Apache brains, stealing the precious memory
from mod_perl :-).
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 12, 2001 8:39 PM
To: Khachaturov, Vassilii
Cc: '[EMAIL PROTECTED]'
Subject: Re: Perl incompat. with apache/mod_perl upgrade
...
Perl
sub WWW_DIR () { $ENV{'HOME'} . '/www' ; } # this sub will persist to next
Perl
... more code, using WWW_DIR sometimes
/Perl
.. more plain apache conf stuff here
Perl
$AxCacheDir = WWW_DIR . '/htdocs/x/cache';
/Perl
While this worked before, it now generates an undef sub called at the
second
...
Was this change intentionally done (why?!), or is it a by-product of some
other code advances?
What is the correct way of passing Perl stuff from one Perl section to
another?
Please read
http://perl.apache.org/guide/config.html#Apache_Configuration_in_Perl
and you will understand how CPerl sections work.
I also don't understand why are you trying to use sub to define a
variable, which is pretty useless, since you use it only during
configuration. Also use the constant pragma.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Perl incompat. with apache/mod_perl upgrade
At 12:26 PM -0500 3/12/01, Khachaturov, Vassilii wrote:
When I upgraded from
Solaris Apache/1.3.14 (Unix) mod_perl/1.24_01
to
Solaris Apache/1.3.17 (Unix) mod_perl/1.25
the following code in my debugging httpd.conf broke:
Perl
sub WWW_DIR () { $ENV{'HOME'} . '/www' ; } # this sub will persist to next
Perl
... more code, using WWW_DIR sometimes
/Perl
When I built Apache 1.3.17 with mod_perl 1.2.5 and numerous other
mods, the resulting httpd was unable to read its usual configuration
file. When I upgraded to Apache 1.3.19 the problem went away.
I'd try 1.3.19.
RE: Perl incompat. with apache/mod_perl upgrade
And, of course, I am using Stas' patent with 'use constant' now... -Original Message- From: Khachaturov, Vassilii Sent: Tuesday, March 13, 2001 2:19 AM To: 'Steve Leibel' Cc: [EMAIL PROTECTED] Subject: RE: Perl incompat. with apache/mod_perl upgrade I've been planning on doing this tomorrow anyhow (w/o any hope), just have to get past some presentation on the existing server with minimal breathing around it. Now, you are the one who gives me a real basis for that hope! Thanks for the tip. Vassilii
