Ed Grimm wrote:
On Wed, 30 Jul 2003, Stas Bekman wrote:
Perrin Harkins wrote:
On Tue, 2003-07-29 at 07:23, Stas Bekman wrote:
That's correct. This is because $r->chdir_file in compat doesn't do
anything. The reason is that under threaded mpm, chdir() affects all
threads. Of course we could ch
On Wed, 30 Jul 2003, Stas Bekman wrote:
> Perrin Harkins wrote:
>> On Tue, 2003-07-29 at 07:23, Stas Bekman wrote:
>>
>>>That's correct. This is because $r->chdir_file in compat doesn't do
>>>anything. The reason is that under threaded mpm, chdir() affects all
>>>threads. Of course we could chec
ColinB wrote:
http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends
I'm a little confused about the changes you've made here. You still
mention using Apache::Registry, and then you added the text that
describes ModPerl::RegistryPrefork but th
--- Stas Bekman <[EMAIL PROTECTED]> wrote:
>
> > This seems to work OK. Hopefully I should now be able to remove the
> > mod_perl 1's Registry.pm file.
> >
> > Thanks everyone.
>
> Perfect. I've replaced the suggestion to use mp1's Apache::Registry
> with this
> better solution, which doesn't
This seems to work OK. Hopefully I should now be able to remove the
mod_perl 1's Registry.pm file.
Thanks everyone.
Perfect. I've replaced the suggestion to use mp1's Apache::Registry with this
better solution, which doesn't require mp1:
http://perl.apache.org/docs/2.0/user/porting/compat.html#C
> Don't mess with the cooker, try using a subclass, e.g.:
>
> # ModPerl/RegistryPrefork.pm
>
> package ModPerl::RegistryPrefork;
>
> use strict;
> use warnings FATAL => 'all';
>
> our $VERSION = '0.01';
>
> use base qw(ModPerl::Registry);
>
> use File::Basename ();
>
> sub handler : method {
PerlResponseHandler ModPerl::Registry
and then re-started the server.
But the printenv script just displays the working directory as "/".
Try the following, instead of ModPerl::RegistryCooker::chdir_file
above:
sub chdir_file_normal {
use File::Basename();
my $file = @_
Perrin Harkins wrote:
On Tue, 2003-07-29 at 07:23, Stas Bekman wrote:
That's correct. This is because $r->chdir_file in compat doesn't do anything.
The reason is that under threaded mpm, chdir() affects all threads. Of course
we could check whether the mpm is prefork and do things the old way, bu
my httpd.conf I replaced
>PerlResponseHandler Apache::Registry
> with
>PerlResponseHandler ModPerl::Registry
> and then re-started the server.
>
> But the printenv script just displays the working directory as "/".
Try the following, instead of ModPerl::RegistryC
On Tue, 2003-07-29 at 07:23, Stas Bekman wrote:
> That's correct. This is because $r->chdir_file in compat doesn't do anything.
> The reason is that under threaded mpm, chdir() affects all threads. Of course
> we could check whether the mpm is prefork and do things the old way, but that
> means t
ndler ModPerl::Registry
and then re-started the server.
But the printenv script just displays the working directory as "/".
Perhaps I've done this wrong? I did notice a couple of lines in the
RegistryCooker.pm file that were already commented out, like this:
#XXX:
ColinB wrote:
Thanks Stas that worked a treat, except that your call to
File::Basename::basename
should be
File::Basename::dirname
The strange reversion to "/" seems to have been cured too.
you are right. Can you please post a working solution, so I'll add it to docs.
BTW, perhaps we shoul
Thanks Stas that worked a treat, except that your call to
File::Basename::basename
should be
File::Basename::dirname
The strange reversion to "/" seems to have been cured too.
Colin
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design s
ir;
}
Thanks Stas. However, this seems to set the working directory to the
server root, not the cgi-bin directory where the script resides.
right, here is another try, again untested:
Index: lib/Apache/compat.pm
===
RCS file: /home/c
... and even stranger, when I invoke the printenv cgi script for the
FIRST time it STILL displays "/" for the working directory, but if I
then click the IE browser's refresh (or CTRL-Refresh) button it changes
to the server root /dir1/dir2/httpd. Subsequent clicks of the refresh
but
;
> chdir $dir;
> }
Thanks Stas. However, this seems to set the working directory to the
server root, not the cgi-bin directory where the script resides. For
example, my printenv script now displays:
...
SCRIPT_FILENAME="/dir1/dir2/httpd/cgi-bin/printenv"
SCRIPT_NAME="/
ColinB wrote:
I'm steadily making progress with getting a collection of mod_perl 1
compatibale scripts working with mod_perl 2 using the backward
compatibility mode.
However, I find that the working directory of all scripts is "/". This
occurs for both ModPerl::Registry and Apache:
I'm steadily making progress with getting a collection of mod_perl 1
compatibale scripts working with mod_perl 2 using the backward
compatibility mode.
However, I find that the working directory of all scripts is "/". This
occurs for both ModPerl::Registry and Apache::Registry. T
Josh Bernstein wrote:
> Sounds great? Does he have anything that I could play with? I'm really
> dying for that chdir(), my programmer says he depends on that
> functionality. I'd even volunteer to do some benchmarks and what not
> associated with the extra overhead of making the function threa
Sounds great? Does he have anything that I could play with? I'm really
dying for that chdir(), my programmer says he depends on that
functionality. I'd even volunteer to do some benchmarks and what not
associated with the extra overhead of making the function thread safe.
If its not really yet
Elizabeth Mattijsen wrote:
> At 06:10 PM 7/16/02 +, Stas Bekman wrote:
>
>>> Arthur told me he either had, or was going to fix this (on IRC).
>>
>> Yup, Arthur is working on an external package (ex::threads::safecwd?)
>> which should solve this problem. Viva Arthur! I'll keep you updated
>>
At 06:10 PM 7/16/02 +, Stas Bekman wrote:
>>Arthur told me he either had, or was going to fix this (on IRC).
>Yup, Arthur is working on an external package (ex::threads::safecwd?)
>which should solve this problem. Viva Arthur! I'll keep you updated once
>it gets released.
Check out Arthur's
Matt Sergeant wrote:
> On Fri, 12 Jul 2002, Stas Bekman wrote:
>
>
>>Josh Bernstein wrote:
>>
>>> After just upgrading to mod_perl2 with Apache2. My current @INC path
>>>includes a "." on the end, which should reference the current working
>
On Fri, 12 Jul 2002, Stas Bekman wrote:
> Josh Bernstein wrote:
> >After just upgrading to mod_perl2 with Apache2. My current @INC path
> > includes a "." on the end, which should reference the current working
> > directory, and therefore correctly locate
Francesc X.Noria wrote:
> On Thu, 11 Jul 2002 16:56:38 -0700
> Josh Bernstein <[EMAIL PROTECTED]> wrote:
>
> : "/". My question is how can I set the working directory to be the
> : location of where the script is running. (This would make mod_perl
> :
On Thu, 11 Jul 2002 16:56:38 -0700
Josh Bernstein <[EMAIL PROTECTED]> wrote:
: "/". My question is how can I set the working directory to be the
: location of where the script is running. (This would make mod_perl
: correctly locate file that I have included in the r
Josh Bernstein wrote:
>After just upgrading to mod_perl2 with Apache2. My current @INC path
> includes a "." on the end, which should reference the current working
> directory, and therefore correctly locate include locate in the script's
> working directo
After just upgrading to mod_perl2 with Apache2. My current @INC path
includes a "." on the end, which should reference the current working
directory, and therefore correctly locate include locate in the script's
working directory. The problem is that the Working Dire
28 matches
Mail list logo
