Perrin Harkins wrote:
On Thu, 2003-07-31 at 15:44, Mark Deepak Puttnam wrote:
sub handler {
my $r=shift;
my $env=$r->subprocess_env;
%ENV=%$senv;
my $referer=$ENV{'HTTP_REFERER'};
x
}
Come to think of it, you should just use the Apache API for this:
my
Hi Perrin,
my $referer = $r->header_in("Referer");
Thanks, the above statement did give me the value.
Mark
I did not have that directive in my config before. But now,I set it
explicitly to PerlSetupEnv On , still no env variables other than the
PERL_SEND_HEADER=On.
Mark
On Thu, 2003-07-31 at 15:44, Mark Deepak Puttnam wrote:
> sub handler {
> my $r=shift;
> my $env=$r->subprocess_env;
>%ENV=%$senv;
>
> my $referer=$ENV{'HTTP_REFERER'};
>
>
>x
>
>
> }
Come to think of it, you should just use the Apache API for
On Thu, 2003-07-31 at 16:15, Mark Deepak Puttnam wrote:
> Only PERL_SEND_HEADER=On. No other env. variables.
And you haven't turned off PerlSetupEnv in your httpd.conf?
- Perrin
Only PERL_SEND_HEADER=On. No other env. variables.
I did run tests by clicking on links to check to see if the HTTP_REFERER
is being set.
Mark.
On Thu, 2003-07-31 at 15:44, Mark Deepak Puttnam wrote:
> I have used the following code in the in my handler and I still do not
> get the values.
Do you get anything at all? HTTP_REFERER is not always sent by
browsers.
- Perrin
Hi Group,
I have a need to access all the %ENV (cgi,mod_perl sent by the client)
variables prior to invoking the content handler. I am using the modperl
environment by running the cgi scripts under Perl::Registry. I wish to
use the PerlTransHandler to check if the request for page A has
orginated
On Fri, 2003-07-25 at 14:55, Levon Barker wrote:
> If I have a $dbh global variable in a particular module that I 'use'. I know
> that Apache::DBI will give a cached connection to the module to use.
There is no need to use a global. Apache::DBI caches it for you. If
you put it in a global, then
Hello,
I have a question.
If I have a $dbh global variable in a particular module that I 'use'. I know
that Apache::DBI will give a cached connection to the module to use.
But what if I do something like $dbh->commit();
Is it possible that I am committing data for another session by accident?
Dennis Stout wrote:
So in startup.perl put
my %queue_list = list_queues;
my %tech_list = list_techs;
and so on?
Then each process would get a copy of the hash?
No, those are lexicals, not globals. Something like this:
package MyCompany::Globals;
use vars qw(%queue_list %tech_list);
%queue_list
> > Is there a way I could get these variables populated on server start and
never
> > loaded again unless the database was changed? So in my subroutine for
posting
> > an event that changed it I could call "repopulate_queue_hash" and have it
redo
> > the hash, s
Dennis Stout wrote:
Is there a way I could get these variables populated on server start and never
loaded again unless the database was changed? So in my subroutine for posting
an event that changed it I could call "repopulate_queue_hash" and have it redo
the hash, so changes stil
In this project I'm making (database), I have several variables with a
potential for a large amount of information to be held in them.
They're all hashes. Some are hashes of hashes...
There is a tech_list, which holds information about each technician.
There is a queue_list which h
[redirecting to the modperl list, as others will want to know the answer as well]
Hi Jamie,
What is the MP2 equivalent of $Apache::ServerStarting? I'm trying to get
Apache::DBI working with MP2.
% grep Server::Starting todo/*
todo/deprecated_features.txt:- $Apache::Server::Starting,
$Apache::Ser
On Mon, 2003-06-09 at 15:24, Perrin Harkins wrote:
> [ Please keep it on the list. ]
>
Sorry about that!
> On Mon, 2003-06-09 at 16:12, Ryan Muldoon wrote:
> > > Ryan, can you post a more complete code example?
> > >
> > > - Perrin
> > Here it is:
> >
> > package Apache::AuthNx509;
> >
> > use
[ Please keep it on the list. ]
On Mon, 2003-06-09 at 16:12, Ryan Muldoon wrote:
> > Ryan, can you post a more complete code example?
> >
> > - Perrin
> Here it is:
>
> package Apache::AuthNx509;
>
> use strict;
> use Apache::Constants qw(:common);
> use Text::ParseWords qw(quotewords);
> use
Actually, upon flushing my browser cache and checking again, I can in
fact read the MOD_PERL environment variable just fine. But still no
luck on any mod_ssl related variables.
--Ryan
Ok, removed. Thank you very much for the in-depth replies. It is very
useful. Unfortunately any variable-reading continues to elude me. But
I really appreciate all the help!
well, it sounds like you are having a larger problem that just mod_ssl-based
variables.
since you mention you&#x
On Mon, 2003-06-09 at 15:35, Geoffrey Young wrote:
> no, I wasn't saying that :) subprocess_env() from the main request is the
> right way to go. I was just trying to let you know that it has nothing to
> do with %ENV really.
I wouldn't go that far. %ENV does get populated with that stuff, ju
; subprocess_env where they sit and wait, presumably for somebody else to call
> add_cgi_vars since mod_ssl does not (but mod_cgi and mod_perl both do).
>
> the problem you're seeing is that these variables are setup during the fixup
> phase, so in using a PerlAuthenHandler
ou
> should be be able to use $r->subprocess_env("SSL_CLIENT_S_DN_CN")
> to get at that info.
>
> Ryan> Currently, I have
> Ryan> PerlPassEnv SSL_CLIENT_S_DN_O
> Ryan> PerlPassEnv SSL_CLIENT_S_DN_CN
> Ryan> in my httpd.conf, but it doesn't seem to make
at 14:26, Issac Goldstand wrote:
> Ryan,
> Ust out of curiosity, at what stage in the request chain are you doing
> this? If you are doing anything before mod_ssl populates its environment
> variables (which I seem to rembmer being at Fixup, although I may be
> confusing with somethi
gt; > PerlPassEnv SSL_CLIENT_S_DN_O
> > PerlPassEnv SSL_CLIENT_S_DN_CN
> > in my httpd.conf, but it doesn't seem to make any kind of difference.
> > To make sure it isn't just mod_ssl being lame for some reason, I've
> > tried it with DOCUMENT_ROOT and other standard ENV variables. But to no
> > avail. :(
>
> Do you have a
>SSLOptions +StdEnvVars
> directive inside the relevant location of your httpd.conf?
for somebody else to call
add_cgi_vars since mod_ssl does not (but mod_cgi and mod_perl both do).
the problem you're seeing is that these variables are setup during the fixup
phase, so in using a PerlAuthenHandler you're trying to see them too early.
int ssl_hook_Fixup(request_re
; don't want to hard-code.
>
> Currently, I have
> PerlPassEnv SSL_CLIENT_S_DN_O
> PerlPassEnv SSL_CLIENT_S_DN_CN
> in my httpd.conf, but it doesn't seem to make any kind of difference.
> To make sure it isn't just mod_ssl being lame for some reason, I've
> trie
Ryan,
Ust out of curiosity, at what stage in the request chain are you doing
this? If you are doing anything before mod_ssl populates its environment
variables (which I seem to rembmer being at Fixup, although I may be
confusing with something else), you wouldn't be able to access them.
ted in the fixup stage, so the mod_ssl
> > environment variables can't be accessed that way. Thanks for the
> > suggestion though!
>
> Okay. And you're certain that a simple $r->subprocess_env('VARIABLE')
> doesn't work? Have you tried setting a variable yourself as a test with
> PerlSetEnv in httpd.conf?
>
> - Perrin
y, I have
Ryan> PerlPassEnv SSL_CLIENT_S_DN_O
Ryan> PerlPassEnv SSL_CLIENT_S_DN_CN
Ryan> in my httpd.conf, but it doesn't seem to make any kind of difference.
Ryan> To make sure it isn't just mod_ssl being lame for some reason, I've
Ryan> tried it with DOCUMENT_ROO
httpd.conf, but it doesn't seem to make any kind of difference.
To make sure it isn't just mod_ssl being lame for some reason, I've
tried it with DOCUMENT_ROOT and other standard ENV variables. But to no
avail. :(
--Ryan
On Mon, 2003-06-09 at 13:59, Geoffrey Young wr
On Mon, 2003-06-09 at 14:49, Ryan Muldoon wrote:
> I tried that as well (and just re-tried). My understanding is that the
> %ENV hash only gets updated in the fixup stage, so the mod_ssl
> environment variables can't be accessed that way. Thanks for the
> suggestion though!
Ryan Muldoon wrote:
I'm not able to get *any* variables out from the apache server
environment.
ok, first off, this is a two step process for Apache. the first step is
that modules (like mod_ssl) populate the subprocess_env table with various
values. then, modules like mod_cgi and mod
I'm using mod_perl 1. But I'm setting the handlers in httpd.conf. I
sent a message to the list on thursday ("problem with pulling variables
from mod_ssl") that more fully describes my situtation.
--Ryan
On Mon, 2003-06-09 at 14:31, Marc M. Adkins wrote:
> IF you
IF you're using mp2...in your httpd.conf are you setting up the handlers
with modperl or perl-script? The former doesn't provide any environment
variables:
http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_
I don't believe this applies to mp1.
mma
I tried that as well (and just re-tried). My understanding is that the
%ENV hash only gets updated in the fixup stage, so the mod_ssl
environment variables can't be accessed that way. Thanks for the
suggestion though!
--Ryan
On Mon, 2003-06-09 at 13:41, Perrin Harkins wrote:
>
On Mon, 2003-06-09 at 14:29, Ryan Muldoon wrote:
> I'm not able to get *any* variables out from the apache server
> environment.
Did you try the normal $ENV{'VARIABLE'} approach?
- Perrin
I'm not able to get *any* variables out from the apache server
environment. As you might be able to imagine, this is extremely
frustrating, and inhibits my ability to do anything of use with
mod_perl. My basic technique has been:
my $uri = $r->uri;
return unless $r-
I'm trying to write an apache authentication module that uses client
certificates for authentication. Basically, all I'm trying to do is use
what mod_ssl does for cert verification, and then set REMOTE_USER. I
wrote to the list last week about a segfault, which was resolved thanks
to the help you
On Wed, Oct 02, 2002 at 06:04:03PM -0500, James G Smith wrote:
> Alan <[EMAIL PROTECTED]> wrote:
> >Greetings again.
> >
> >I'm trying to figure out the best/fastest/most elegant way of setting
> >virtualhost based variables. Basically I have three sites, a
Alan <[EMAIL PROTECTED]> wrote:
>Greetings again.
>
>I'm trying to figure out the best/fastest/most elegant way of setting
>virtualhost based variables. Basically I have three sites, and the only
>difference between them is the DocumentRoot ($htdocroot) and the dat
Greetings again.
I'm trying to figure out the best/fastest/most elegant way of setting
virtualhost based variables. Basically I have three sites, and the only
difference between them is the DocumentRoot ($htdocroot) and the database
their data is being accessed from ($dbh).
When it
inal request. If this
original request was for a mod_perl module, then it doesn't recieve
it's appropriate @INC. The environment variables are all set properly,
ie: PERL5LIB is what is supposed to be, it's just that the @INC hasn't
be rebuilt.
Does anyone know if this is a bug
Hi!
I'm using
Apache::Registry and have the problem that sometimes ENV{'HTTP_COOKIE'} does not
contain the real cookie value, instead it holds the cookie of an user, who has
used my mod_perl-script some seconds before.
Is there any way I
can fix this problem, e.g. initialitzing the ENV-has
Ken Y. Clark wrote:
> As for this and Perrin's comment about parsing on your own, the point
> is that you've written a lot of code that has already been written and
> debugged by a lot of really smart people. There's no reason for you
> to be reading STDIN and spliting and all that. If you're us
On Tue, 13 Aug 2002, Michael Drons wrote:
> Date: Tue, 13 Aug 2002 07:46:16 -0700 (PDT)
> From: Michael Drons <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: Perrin Harkins <[EMAIL PROTECTED]>,
> darren chamberlain <[EMAIL PROTECTED]>
> Cc: [EMAIL
Sorry, There is a my in front of the ($cookie,$user)
code. I am confused about your second statement about
parsing the input. What should I be doing? Do you
mean I should use $r->read($content,
$r->header_in('Content-length'))? to read in the
variables?
I use the AuthCooki
darren chamberlain wrote:
> Make those global symbols ($cookie, $user, and $hash) lexical (declare
> with my) and the code will both compile and do what you expect (i.e.,
> not maintain values from call to call).
That's what I was thinking too. Also, it's really not a good idea to do
your own p
00);> my $auth_type = $r->auth_type;> $cookie=$auth_type->key;> ($user,$hash)=split(/:/,$cookie);> read(STDIN, my $buffer, $ENV{'CONTENT_LENGTH'});> my @pairs = split(/&/, $buffer);> foreach my $pair (@pairs) {> > }>> What I am doing wr
my $pair (@pairs) {
>
> }
>
> What I am doing wrong? Everytime the script runs the
> values of the variables coming in change. Should I
> use the delete function and delete all of the
> variables at the end of the script? @pairs is what
> should change, but sometimes d
I'm sure someone will correct me if I'm wrong...
But, variables in the initial section (ie outside of a function) in the main
package will stay in scope all the time. This means that it will retain the
value from a previous request- which might be giving you these problems.
As Perr
$cookie=$auth_type->key;
($user,$hash)=split(/:/,$cookie);
read(STDIN, my $buffer, $ENV{'CONTENT_LENGTH'});
my @pairs = split(/&/, $buffer);
foreach my $pair (@pairs) {
}
What I am doing wrong? Everytime the script runs the
values of the variables coming in change. Should I
u
Michael Drons wrote:
> I am using Apache::Registry (Apache 1.3.26) I am see
> weird things happen with my scripts. I have have "use
> strict" in all of the scripts and I use my() for all
> of my variables. But I still have variables that
> contain data from previou
I am using Apache::Registry (Apache 1.3.26) I am see
weird things happen with my scripts. I have have "use
strict" in all of the scripts and I use my() for all
of my variables. But I still have variables that
contain data from previous loads. I see it in hashes
and arrays. Especi
The answer to the trick question is that the subroutine name in package
Sub::First is misspelled (missing a "t").
However, I think I would provide the Apache::Log object as a parameter to
new() rather than twiddling with package vars to try to have it magically
updated by Exporter. For example:
Viljo Marrandi actually wrote:
>my $r = shift;
>use vars qw( $log );
>$log = $r->log();
>
>if ( $some_case eq 'true' ) {
> use Sub::First qw( $log );
I haven't tested, but this doesn't look as a good idea.
I don't think your code does what you think it does
(or what you thi
d.pm use Export.pm exactly same way. So, it this some
mod_perl specific feature to just eat up some variables, or what?
Here are cut-down versions of my modules:
Site.pm:
-
package Site;
use strict;
use Apache::Log;
sub handl
Bill Catlan wrote:
> Stas Bekman wrote:
>
>
>>This explains why by default %ENV is set for each request afresh.
>>http://perl.apache.org/guide/performance.html#PerlSetupEnv_Off
>
>
> Great. Thank you Stas. Now I know /how/ that happens, but I don't know /why/
> the existing inctances' ENV is
tly, and don't seem to have any
> troubles.
Okay, local takes a temporary copy of the variable and then restores the
original value at the end of the block. It's the same variable though. my
creates a new variable that is only visible from within the block and
can't be seen from ot
ml) states:
>
> "Special Perl variables like $| (buffering), $^T (script's start time), $^W
> (warnings mode), $/ (input record separator), $\ (output record separator) and
> many more are all true global variables; they do not belong to any particular
> package (not even ma
You'll also need to use a PerlPassEnv directive prior to your block.
For debug purposes, try adding the following inside your block:
print join("\n", map { "$_ => $ENV{$_}" } (keys %ENV)), "\n";
OR, my personal quick-debugging catch-all:
use Data::Dumper;
print Dumper \%ENV;
You'll be able
> I thought that using 'local' would successfully scope those globals to
> within a sub, so you could,k for example, slurp an entire file by doing:
>
> local $/ = undef;
> my $file = ;
>
> Or am I wrong in that? I use it frequently, and don't seem to have any
> troubles.
>
> --Jon R.
It is my un
Stas Bekman wrote:
> This explains why by default %ENV is set for each request afresh.
> http://perl.apache.org/guide/performance.html#PerlSetupEnv_Off
Great. Thank you Stas. Now I know /how/ that happens, but I don't know /why/
the existing inctances' ENV is not clobbered.
My guess is that a
Bill Catlan wrote:
> Hello,
>
> The online mod_perl guide
> (http://thingy.kcilink.com/modperlguide/perl/The_Scope_of_the_Special_Perl_Va.ht
> ml) states:
>
> "Special Perl variables like $| (buffering), $^T (script's start time), $^W
> (warnings mode), $/ (i
Hello,
The online mod_perl guide
(http://thingy.kcilink.com/modperlguide/perl/The_Scope_of_the_Special_Perl_Va.ht
ml) states:
"Special Perl variables like $| (buffering), $^T (script's start time), $^W
(warnings mode), $/ (input record separator), $\ (output record separator) and
man
What I was really looking for was $r->server_root_relative. =) Thanks
Geoff!
That's to all for your help.
-Fran
> You'll also need to use a PerlPassEnv directive prior to your
> block.
>
> For debug purposes, try adding the following inside your block:
>
> print join("\n", map { "$_ => $
On Wednesday, May 1, 2002, at 05:04 AM, Fran Fabrizio wrote:
>
> I spoke too soon.
>
> I need:
>
>
> push @Alias, [ qw(/cgi-bin/chimpkit/ $ENV{SERVER_ROOT}/cgi-
> bin/chimpkit/) ];
>
>
> This does not appear to be possible because there's no way to
> pass in SERVER_ROOT to the apache startu
Fran Fabrizio wrote:
>
> I spoke too soon.
>
> I need:
>
>
> push @Alias, [ qw(/cgi-bin/chimpkit/
> $ENV{SERVER_ROOT}/cgi-bin/chimpkit/) ];
>
>
> This does not appear to be possible because there's no way to pass in
> SERVER_ROOT to the apache startup. I have SERVER_ROOT getting set
I spoke too soon.
I need:
push @Alias, [ qw(/cgi-bin/chimpkit/ $ENV{SERVER_ROOT}/cgi-bin/chimpkit/) ];
This does not appear to be possible because there's no way to pass in SERVER_ROOT to
the apache startup. I have SERVER_ROOT
getting set in root's .bashrc, but when I execute ./apachec
Yikes, I just found an example of the exact thing I needed in the
cookbook (recipe 2.16). Sorry, and thanks!
-Fran
Yup. See the directive. Good description of how it works in
the Eagle Book.
-- Fran Fabrizio <[EMAIL PROTECTED]>
>
> I am trying to make a portable mod_perl.conf. I have things like:
>
> Alias /cgi-bin/chimpkit/ /usr/local/apache/cgi-bin/chimpkit/
>
> SetHandler perl-script
> Perl
I am trying to make a portable mod_perl.conf. I have things like:
Alias /cgi-bin/chimpkit/ /usr/local/apache/cgi-bin/chimpkit/
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader On
which really needs to become something like:
Alias /cgi
I have set 'PerlSetVar UseStrict 1' because I always use
> sctict anyway and I see in the docs that this might become the default
> too. So I always declare my variables with my().
>
> Suppose I have a master ASP file that includes other scripts and these
> other scrip
In my httpd.conf I have set 'PerlSetVar UseStrict 1' because I always use
sctict anyway and I see in the docs that this might become the default
too. So I always declare my variables with my().
Suppose I have a master ASP file that includes other scripts and these
other scripts need
> -Original Message-
> From: Chui G. Tey [mailto:[EMAIL PROTECTED]]
>
> package Apache::MyPkg;
>
> my $COM_instance;
>
> sub handler {
>
>if (!$COM_instance) {
>$COM_instance = Win32::OLE->new("ProgID.Class");
>}
>
> }
>
> Will the different child processes created by
to file on every
> request. So I have defined the variable as a package level variable.
Package level variables are shared upon fork(), in the sense that
the memory segment(s) they use is made available to all child
processes. BUT the memory itself isn't shared, and any subsequent
write to t
> Will the different child processes created by Apache share the same
> variable? Or will each child create an additional instance?
Each child has a separate interpreter and thus a separate instance of
your global. If you need to co-ordinate data between processes, you
might want to look at Cach
These instances are too large to write and read to file on every
> request. So I have defined the variable as a package level variable.
>
> I have been instantiating the variable in my handler() routine if it has
> not already been instantiated. ie.
Global variables are exactly that
I have some state data that I need to persist between requests. At the
moment these are COM objects, but they'll be ported to Perl Classes. It
is quite important that only one of these instances exist per web
server. These instances are too large to write and read to file on every
request. So I ha
I'm working on a project that is highly configurable via environment
variables.
I'd like a way to get those environment variables into my mod_perl
processes so that the mod_perl portion of this project can be configured
the same way as the non mod_perl portions.
I know that
On Fri, 24 Aug 2001, Eric Hammond wrote:
> Is there any way to take the Apache::ReadConfig name space
> (variables set in sections) and generate plain text
> Apache directives?
I don't know if there is a simple answer to this one, but the way I would
handle it is to scrap the
Is there any way to take the Apache::ReadConfig name space
(variables set in sections) and generate plain text
Apache directives?
For example, assuming some_function() returns "myhost", I would
like to convert the variables generated by:
$ServerName = som
s explicit package name" I know, this is a
> question which may be not right here !
> I don`t want to use the perlmodule CGI !!
>
> I hope some persons can help me,
primarily, global variables are looked down upon.
but like the error message says, you can explicitly name an
Hi all,
i want to define a global variable which is also present in subroutines
coded in
extra perl modules.
I tried this "our $test;" but amod_perl tells me following "Global
symbol "$test" requires explicit package name" I know, this is a
question which may be not right here !
I don`t want to
Scott Alexander ([EMAIL PROTECTED]) said something to this effect on
04/27/2001:
> Should this work in a startup.pl file
>
> my $hostname = $ENV{"HOSTNAME"} ;
>
> from the prompt I can write echo $HOSTNAME and get the correct
> hostname of the server.
>
> But from within startup.pl I don't g
On Sun, 29 Apr 2001, Philip Mak wrote:
> Is it possible to rewrite this perl subroutine without using variables?
>
> sub XMLEncode {
> my ($line) = @_;
> $line =~ s/&/&/g;
> $line =~ s/ $line =~ s/>/>/g;
> return $line;
> }
>
> I w
On Sun, Apr 29, 2001 at 04:34:40AM -0400, Philip Mak wrote:
>
> I was thinking something like
>
> sub XMLEncode {
local $_ = shift;
> s/&/&/g;
> s/ s/>/>/g;
> return $_;
> }
--
Honza Pazdziora |
Is it possible to rewrite this perl subroutine without using variables?
sub XMLEncode {
my ($line) = @_;
$line =~ s/&/&/g;
$line =~ s//>/g;
return $line;
}
I was thinking something like
sub XMLEncode {
s/&/&/g;
s//>/g;
return $_;
}
but I can
Hi there,
On Fri, 27 Apr 2001, Philip Mak wrote:
> On Fri, 27 Apr 2001, Scott Alexander wrote:
>
> > Should this work in a startup.pl file
> >
> > my $hostname = $ENV{"HOSTNAME"} ;
> > from the prompt I can write echo $HOSTNAME and get the correct hostname of the
>server.
> > But from within s
On Fri, 27 Apr 2001, Scott Alexander wrote:
> Should this work in a startup.pl file
>
> my $hostname = $ENV{"HOSTNAME"} ;
>
> from the prompt I can write echo $HOSTNAME and get the correct
> hostname of the server.
>
> But from within startup.pl I don't get it.
The reason "echo $HOSTNAME" works
Should this work in a startup.pl file
my $hostname = $ENV{"HOSTNAME"} ;
from the prompt I can write echo $HOSTNAME and get the correct
hostname of the server.
But from within startup.pl I don't get it.
Scott
http://perl.apache.org/guide/porting.html#Configuration_Files_Writing_Dy
Guide Good!
"Warren D. Johnson" wrote:
> Hello All,
>
> I apologize if this is in a FAQ somewhere.
>
> I have a script, lets call it test.pl. Test.pl requires in config.pl.
>
> Test.pl use
Hello All,
I apologize if this is in a FAQ somewhere.
I have a script, lets call it test.pl. Test.pl requires in config.pl.
Test.pl uses variables (via use vars) from config.pl. These variables are
defined and given values in config.pl. AFter the first usage of test.pl,
the variables we are
ring data between your processes, and this
is a topic often discussed on this List. You might like to search the
archives for things like DBM, tied hash, database, shared data, shared
variables. There are links to search engines on the mod_perl home
page. Also there are one or two things in the DIG
correct but
perhaps it has forgotten all the global filled variables - what
happens.
I called the Dumper
\@ARTIKEL and he says the array is filled, but next time the array is empty -
what is my failure???
Please help
me
I am looking forward
to your answer
with
greetings
Werner
; unicode
> support. 5.6.0 has a lot of bugs (witch were fixed in 5.7.0)
>
> Best
> Cb
>
> - Original Message -
> From: "Jauder Ho" <[EMAIL PROTECTED]>
> To: "Bogomolnyi Constantin" <[EMAIL PROTECTED]>
> Sent: Monday
icode
support. 5.6.0 has a lot of bugs (witch were fixed in 5.7.0)
Best
Cb
- Original Message -
From: "Jauder Ho" <[EMAIL PROTECTED]>
To: "Bogomolnyi Constantin" <[EMAIL PROTECTED]>
Sent: Monday, March 19, 2001 8:44 AM
Subject: Re: perl5.6 (was: Shared variabl
On Fri, 16 Mar 2001, Bogomolnyi Constantin wrote:
> You should probably try 5.7.0 witch is much more stable than 5.6.0 (you
> should not try unicode stuff , whitch is quite buggy)
>
> I use 5.7.0 on all my production servers without any problems .
5.7.0 may have fixed some of the bugs of 5.6.0
quot;modperl" <[EMAIL PROTECTED]>
Sent: Saturday, March 17, 2001 6:20 AM
Subject: Re: perl5.6 (was: Shared variables, inner subs and "our")
> Stas Bekman wrote:
>
> > our() and other perl5.6 new APIs are too early to be endorsed, as 5.6 is
> > not yet
On Fri, 16 Mar 2001, Wim Kerkhoff wrote:
> Stas Bekman wrote:
>
> > our() and other perl5.6 new APIs are too early to be endorsed, as 5.6 is
> > not yet considered as a stable version for mod_perl production sites,
> > therefore the guide barely touches on it.
>
> Would you recommend the use of p
Stas Bekman wrote:
> our() and other perl5.6 new APIs are too early to be endorsed, as 5.6 is
> not yet considered as a stable version for mod_perl production sites,
> therefore the guide barely touches on it.
Would you recommend the use of perl5.6 with mod_perl? What you are
saying is making m
1 - 100 of 232 matches
Mail list logo
