One thing we should be clear about: mod_perl is EXACTLY regular Perl.
There are no differences in how the Perl code is interpreted. The
interpreter is not crippled or modified, it just processes Perl like it
usually does.
The only difference is that your code may be run several times in a row,
without cleaning up between runs. So for a more accurate test, copy and
paste your code so that you repeat the exact text seven times in a row
in the same program, then run that program. That's closer to what's
going to happen in mod_perl when the code is run several times for
repeated requests.
When you do this experiment, you'll see why you can get away with
writing sloppy code with dangling variables, dynamically scoped or
global variables, etc. when you're running CGI, but this level of
sloppiness doesn't work when you're dealing with mod_perl.
It's been said here before, so take the advice: use "use strict" in your
code. ALWAYS under mod_perl. It will help you catch these mistakes,
and people won't help you if you won't at least take that step.
[EMAIL PROTECTED] (Andrei A. Voropaev) wrote:
>Since the broken code worked in regular perl (and it was supposed to work
>because $rech and %rech are different things) and it didn't want to work
>in emb perl then there must be something strange about it.
>
>Was it an error in testing code (ie. checking $rech->{keys} instead of
>$rech{keys} at the end) or emb perl puts some restrictions on variables that
>I can use? Again. There's nothing wrong from the regular perl stand point if
>I say $rech = {}; and then $rech{'key'} = $value; perl creates different
>variables and as long as I use them correctly there shouldn't be a problem.
>Of course if I try to access $rech->{'key'} I'll get empty value later :)
>
>So, was it an error in real testing code? Because the code that I saw didn't
>contain that error.
------------------- -------------------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED] The Math Forum
