pod files
A relatively trivial point, but I notice that the pod files cgi_to_mod_perl.pod mod_perl.pod mod_perl_tuning.pod which were supplied with mod_perl 1 are missing from mod_perl 2 (perhaps because they need re-writing?) Is it indended to include these in the final mod_perl 2 release? Thanks Colin __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Working directory of script is / !
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 {
my $class = (@_ = 2) ? shift : __PACKAGE__;
my $r = shift;
return $class-new($r)-default_handler();
}
sub chdir_file {
use File::Basename();
my $file = @_ == 2 ? $_[1] : $_[0]-{FILENAME};
my $dir = File::Basename::dirname($file);
chdir $dir or die Can't chdir to $dir: $!;
}
1;
I copied this into a new file RegistryPrefork.pm in the same
directory as the ModPerl Registry.pm in the perl tree, and changed the
PerlResponseHandler ModPerl::Registry
line in startup.pl to
PerlResponseHandler ModPerl::RegistryPrefork
and restored the RegistryCooker.pm file to its original contents. I
also removed the Apache::RequestRec::chdir_file definition in my
startup.pl
This seems to work OK. Hopefully I should now be able to remove the
mod_perl 1's Registry.pm file.
Thanks everyone.
Colin
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: Working directory of script is / !
--- 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 require mp1: 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 then use it via PerlResponseHandler Apache::RegistryPrefork __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Working directory of script is / !
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. This causes many scripts to fail because they call open() using a relative pathname. Surely the working directory of a script should be the directory in which it resides? It does not seem to matter what directory I am in when I invoke httpd; the script's current directory is always /. I am mystified. Here is the output from a simple printenv cgi script (with some of the env variables snipped for brevity), which also prints the working directory using getcwd (and invokes ld -al to list the contents of the current directory): Content-type: text/plain DOCUMENT_ROOT=/dir1/dir2/httpd/htdocs EXITSERVERLOC=http://localhost/cgi-bin/index.cgi; GATEWAY_INTERFACE=CGI-Perl/1.1 HOME=/mps/home/cdi HTTP_ACCEPT=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/x-shockwave-flash, */* HTTP_ACCEPT_ENCODING=gzip, deflate HTTP_ACCEPT_LANGUAGE=en-gb HTTP_CONNECTION=Keep-Alive HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 5.01; Windows NT) MOD_PERL=mod_perl/1.99_09 QUERY_STRING= REQUEST_METHOD=GET REQUEST_URI=/cgi-bin/printenv SCRIPT_FILENAME=/dir1/dir2/httpd/cgi-bin/printenv SCRIPT_NAME=/cgi-bin/printenv SERVER_PORT=8000 SERVER_PROTOCOL=HTTP/1.1 SERVER_SIGNATURE=addressApache/2.0.46 (Unix) mod_perl/1.99_09 Perl/v5.8.0 Server at homer Port 8000/address\n SERVER_SOFTWARE=Apache/2.0.46 (Unix) mod_perl/1.99_09 Perl/v5.8.0 TZ=GB Working directory is / total 329 drwxr-xr-x 36 root root1024 Jul 16 09:50 . drwxr-xr-x 36 root root1024 Jul 16 09:50 .. lrwxrwxrwx 1 root root 9 Jun 19 09:59 bin - ./usr/bin drwxr-xr-x 2 root root 512 Jun 27 14:42 cdrom drwxr-xr-x 16 root sys 4608 Jun 27 15:44 dev drwxr-xr-x 4 root sys 512 Jun 19 10:28 devices drwxr-xr-x 51 root sys 3584 Jul 18 14:04 etc drwxr-xr-x 3 root sys 512 Jun 19 09:57 export and so on... __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Working directory of script is / !
--- Stas Bekman [EMAIL PROTECTED] wrote:
... I won't commit it yet, but you can override it in your
startup.pl,
until the dust settles down:
require Apache::compat;
sub Apache::RequestRec::chdir_file {
my $dir = @_ == 2 ? $_[1] : $_[0]-filename;
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=/cgi-bin/printenv
...
Working directory is /dir1/dir2/httpd
total 54
drwxrwxr-x 15 sxi_user other512 Nov 28 2001 .
drwxrwxr-x 4 sxi_user sxi 512 Jul 29 10:58 ..
drwxrwxr-x 2 sxi_user sxi 512 Jul 18 15:57 bin
drwxrwxr-x 2 sxi_user sxi 512 Jul 18 15:57 build
drwxrwxr-x 9 sxi_user sxi 1024 Jul 29 11:38 cgi-bin
drwxrwxr-x 2 sxi_user sxi 512 Aug 16 2000 conf
...
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: Working directory of script is / !
... 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 button continue to show the server root. Howvever, if I leave the browser inactive for about 30 secs or so and then click refresh again, I get the working directory / again. Sunsequent rereshes display the server root pathname again. Very strange. Colin __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Working directory of script is / !
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 software http://sitebuilder.yahoo.com
Re: Working directory of script is / !
Can you please post a working solution, so I'll add it
to docs.
I added this to my startup.pl just after the
use Apache::compat();
sub Apache::RequestRec::chdir_file {
use File::Basename();
my $file = @_ == 2 ? $_[1] : $_[0]-filename;
my $dir = File::Basename::dirname($file);
chdir $dir or die Can't chdir to $dir: $!;
}
BTW, perhaps we should enable the chdir_file call in
ModPerl::RegistryCooker,
so people won't need to install mod_perl 1 just to have
Apache::Registry...
can you please try with ModPerl::RegistryCooker?
Well I commented out the following line in
perl/lib/site_perl/5.8.0/sun4-solaris/Apache2/ModPerl/RegistryCooker.pm
like this:
#*chdir_file = \NOP;
and added an identical definition to the above in my startup.pl file
like this:
sub ModPerl::RegistryCooker::chdir_file {
use File::Basename();
my $file = @_ == 2 ? $_[1] : $_[0]-filename;
my $dir = File::Basename::dirname($file);
chdir $dir or die Can't chdir to $dir: $!;
}
and then in 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 /.
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: $self-chdir_file($Apache::Server::CWD/);
I don't know if that's significant?
Colin
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Can't locate object method cgi_env
I'm trying to get some perl scripts that work OK under mod_perl 1 working in mod_perl 2. I'm therefore using the mod_perl 1 backward compatiblity, and also the Apache::Registry from mod_perl 1 (as described in the mod_perl 2 documentation to get around the chdir() problem). One of the scripts sets up a request handler, but when it tries to execute: $r-cgi_env(AB_AUTHHOST=$host); the following error appears in the httpd log file: Can't locate object method cgi_env via package Apache::RequestRec at /path/to/perl/lib/site_perl/Apache/MyModule.pm line 55 I have tried to search the perl.apache.org site for cgi_env, but no matches found. I have also tried to search all of the files in the perl 5.8.0 and mod_perl 2 distribution for occurences of cgi_env, and the ONLY place it occurs is in mod_perl-1.99_09/todo/deprecated_features.txt which lists several $r methods (including $r-cgi_env) and says that: these features will either: a) never be in 2.0 b) only be in if #ifdef MP_DEPRECATED c) be in a form that was nothing like 1.xx d) split off into something standalone on cpan So if $r-cgi_env has been REMOVED from mod_perl 2, what is the recommended alternative for it? Thanks, Colin __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Can't locate object method cgi_env
--- Stas Bekman [EMAIL PROTECTED] wrote: Stas Bekman wrote: ColinB wrote: One of the scripts sets up a request handler, but when it tries to execute: $r-cgi_env(AB_AUTHHOST=$host); I have never used that API, but I believe you misuse it. I think it should be: $r-subprocess_env(AB_AUTHHOST=$host); which works in mp1 and mp2. Thanks Stas. That seems to have fixed that problem. I'm going to commit this (in case you don't want/can't s/cgi_env/subprocess_env/) snip Thanks again. This is all pretty new to me and I'm not (yet) familiar with the procedures for submitting changes to source or documentation. Colin __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Apache::Registry in mod_perl 2
--- Stas Bekman [EMAIL PROTECTED] wrote: ColinB wrote: So how can I go about installing just Apache::Registry from the mod_perl 1 tar file without having to install ALL of mod_perl 1 ? simply copy it into one of the dirs in your @INC. You will also need to load Apache::compat for it to work. Thanks. I've untarred mod_perl 1.0 and searched for any Registry* filnames: ./lib/Apache/RegistryBB.pm ./lib/Apache/RegistryNG.pm ./lib/Apache/Registry.pm ./lib/Apache/RegistryLoader.pm Do I need to copy ALL of these files (and maybe others?) or just the ./lib/Apache/Registry.pm file? __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Apache::Registry in mod_perl 2
This page: http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends says that mod_perl 2's ModPerl::Registry does not chdir() into the script's directory, wheras mod_perl 1's Apache::Registry DOES chdir(). It also says that this will eventually be fixed by the time mod_perl 2 is released, and in the meantime you can use the Apache::Registry (which is part of mod_perl 1) in mod_perl 2. As I will be trying to get some old scripts working in mod_perl 2, it seems prudent to use Apache::Registry. So how can I go about installing just Apache::Registry from the mod_perl 1 tar file without having to install ALL of mod_perl 1 ? Colin __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Is statically-compiled mod_perl better?
What is the preferred method of compiling mod_perl - static or dynamic? I have read that *static* linking is likely to load and execute faster, but may be wasteful of resources if there are multiple proceses each with its own copy of the common code. It therefore seems likely that a statically compiled mod_perl would be faster, provided that a large number of httpd's are not being run at the same time. Is this correct? It seems that at present it is not possible to build mod_perl 2.0 statically. It can only be built dynamically and loaded using LoadModule in httpd.conf. This seems strange if the preferred method of building is static. Thanks Colin __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Re: Is statically-compiled mod_perl better?
Thanks for the comments. I guess I'll just have to stick with the dynamically-linked mod_perl 2.0 for the time being. I'll keep checking the mod_perl 2.0 site pages and pick up a static-capable version when it becomes available. Colin __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
