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 / !
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::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 /.
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 that the same code won't work the same under threaded and non-threaded
mpms. Hence the limbo. Still waiting for Arthur to finish porting safecwd
package, which should resolve this problem.
Meanwhile try this patch:
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.86
diff -u -r1.86 compat.pm
--- lib/Apache/compat.pm28 Jul 2003 10:33:58 - 1.86
+++ lib/Apache/compat.pm29 Jul 2003 11:19:46 -
@@ -335,6 +335,8 @@
sub chdir_file {
#XXX resolve '.' in @INC to basename $r-filename
+my $dir = @_ == 2 ? $_[1] : $_[0]-filename;
+chdir $dir;
}
sub finfo {
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;
}
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.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 / !
ColinB wrote:
--- 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.
right, here is another try, again untested:
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.86
diff -u -r1.86 compat.pm
--- lib/Apache/compat.pm28 Jul 2003 10:33:58 - 1.86
+++ lib/Apache/compat.pm29 Jul 2003 13:31:24 -
@@ -40,6 +40,8 @@
use mod_perl ();
use Symbol ();
+use File::Basename ();
+
BEGIN {
$INC{'Apache.pm'} = __FILE__;
@@ -335,6 +337,9 @@
sub chdir_file {
#XXX resolve '.' in @INC to basename $r-filename
+my $file = @_ == 2 ? $_[1] : $_[0]-filename;
+my $dir = File::Basename::basename($file);
+chdir $dir or die Can't chdir to $dir: $!;
}
sub finfo {
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod perl , windows/apache problem
On Mon, 28 Jul 2003, Erik Browaldh wrote: I have written a program that takes argument from html-formula and read and write it to a textfile. When I tried it with perl mod 2, under windows with apache it doesnt work anymore. No new entries are written to the log-file.txt Ive tried chmod, especially r/w accesses but that doesnt seem to help. [ ... ] alarm(30); As Mustafa mentioned in another reply, you might want to try it without the flock() below [and also perhaps try without the alarm() call above]. Also, any messages in the error log would be helpful. [ ... ] open T,log-file.txt || die cant open T for write $!; flock T,2; # write lock [ ... ] open (T,log-file.txt) || die Cant open file T for read $!; flock T,1; As Stas explained in another thread today, the directory in which these files have been opened may not be the one in which your script resides. Try giving the full path to any files you're opening. -- best regards, randy kobes
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 / !
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 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? Thanks. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod perl , windows/apache problem
Randy Kobes wrote: On Mon, 28 Jul 2003, Erik Browaldh wrote: I have written a program that takes argument from html-formula and read and write it to a textfile. When I tried it with perl mod 2, under windows with apache it doesnt work anymore. No new entries are written to the log-file.txt Ive tried chmod, especially r/w accesses but that doesnt seem to help. [ ... ] alarm(30); As Mustafa mentioned in another reply, you might want to try it without the flock() below [and also perhaps try without the alarm() call above]. Also, any messages in the error log would be helpful. [ ... ] open T,log-file.txt || die cant open T for write $!; flock T,2; # write lock [ ... ] open (T,log-file.txt) || die Cant open file T for read $!; flock T,1; As Stas explained in another thread today, the directory in which these files have been opened may not be the one in which your script resides. Try giving the full path to any files you're opening. and Colin will post shortly a workaround until we provide an in-core solution. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Apache-print() problem with UTF-8 data in Perl 5.8
Is anybody going to take a serious look at the problem that I previously reported with Apache-print()'s handling of UTF-8 data in Perl 5.8? The patch that I sent (http://marc.theaimsgroup.com/?l=apache-modperlm=105912130001046w=2) seems to fix it for me on Windows as long as I've got perl #20203 incorporated. Does it work on other platforms? The #ifdef version-checks need a little work: on Windows (and other platforms [-- which ones?] that rely on Perl's makedef.pl to get symbols exported from the Perl library) you need perl-5.8.1; on other platforms the test for perl-5.8.0 should be fine. The brokenness of Apache-print() under perl-5.8.0 on Windows et al would also need documenting somewhere since it can't be fixed properly. Maybe it's just easier to change the version-checks to 5.8.1 for all platforms, and document the broken behaviour under 5.8.0? Steve
http responses piped to STDERR
I'm (very) occasionally seeing the output of Apache::Registry scripts sent to STDERR instead of STDOUT. That is, the entire http response (headers included) appears in my error log, while nothing at all is displayed to the client. Could someone kick me towards what I should look into here? thanks, michael
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
Re: Apache-print() problem with UTF-8 data in Perl 5.8
Steve Hay wrote: Is anybody going to take a serious look at the problem that I previously reported with Apache-print()'s handling of UTF-8 data in Perl 5.8? Steve, At the moment I'm busy fixing things for p5.8.1 for which mod_perl 2.0 is one of the showstoppers and Jarkko really wants to release 5.8.1 now. Once finished (should be soon) I will take care of all the outstanding issues, and there are quite a few. I apologize for not following up on those. Of course if someone else is willing to help, that would be *very* helpful. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-print() problem with UTF-8 data in Perl 5.8
On Tue, 29 Jul 2003, Steve Hay wrote: Is anybody going to take a serious look at the problem that I previously reported with Apache-print()'s handling of UTF-8 data in Perl 5.8? The patch that I sent (http://marc.theaimsgroup.com/?l=apache-modperlm=105912130001046w=2) seems to fix it for me on Windows as long as I've got perl #20203 incorporated. Does it work on other platforms? The #ifdef version-checks need a little work: on Windows (and other platforms [-- which ones?] that rely on Perl's makedef.pl to get symbols exported from the Perl library) you need perl-5.8.1; on other platforms the test for perl-5.8.0 should be fine. The brokenness of Apache-print() under perl-5.8.0 on Windows et al would also need documenting somewhere since it can't be fixed properly. Maybe it's just easier to change the version-checks to 5.8.1 for all platforms, and document the broken behaviour under 5.8.0? mod_perl 2 makes two special cases for handling systems that use export files - Win32 and aix ($^O eq 'aix'). So these might be the only two one has to worry about in this regard. I take it this is a problem in principle on all platforms running perl-5.8? If so, what might work is, for all platforms running 5.8.x, apply the patch, except for Win32 and aix (I'm not sure of aix), which would require 5.8.1. So something like #if PERL_VERSION = 8 #if ( defined(WIN32) || defined(_AIX) ) PERL_SUBVERSION = 1 #endif #endif And then, as you say, document the broken behaviour under Win32 (and aix?) for 5.8.0. -- best regards, randy
ANNOUNCE: AxKit 1.6.2
The AxKit Development Team are proud to announce the release of AxKit 1.6.2. This release is a minor bug fix and small features release. You can download AxKit 1.6.2 from http://xml.apache.org/dist/axkit/ or via a CPAN mirror once CPAN propogates. Changes in this release: - Made processors added via AxAddDynamicProcessor appear in their proper order based on the order in which they appear in the config files (rather than simply appended on to the current processing chain). - AxAdd*Processor outside of AxStyleName blocks now are global, instead of in the '#default' style name - XSP attribute values are now interpolated like in XSLT, to save you having xsp:attribute tags all over your XSP code. - Added a test suite based on Apache::Test (yay!) - A number of XSP bug fixes - Support HTTP HEAD requests - Custom content providers now interact properly with the dependency tests - AxTraceIntermediate now creates the dir if it didn't exist - Other assorted minor bug fixes -- !-- Matt -- :-get a SMart net/:- Spam trap - do not mail: [EMAIL PROTECTED]
Re: Working directory of script is / !
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 that the same code won't work the same under threaded and non-threaded mpms. Hence the limbo. Still waiting for Arthur to finish porting safecwd package, which should resolve this problem. When he does finish it, won't we make the threaded MPM work just like this? It seems like it would be reasonable to get prefork working properly, even if the threaded MPM isn't ready yet. - Perrin
Re: Apache-print() problem with UTF-8 data in Perl 5.8
Stas Bekman wrote: Steve Hay wrote: Is anybody going to take a serious look at the problem that I previously reported with Apache-print()'s handling of UTF-8 data in Perl 5.8? Steve, At the moment I'm busy fixing things for p5.8.1 for which mod_perl 2.0 is one of the showstoppers and Jarkko really wants to release 5.8.1 now. Is there a problem with mod_perl 1.28 under the forthcoming perl 5.8.1 as well? I just tried out Jarkko's latest release (http://www.iki.fi/jhi/[EMAIL PROTECTED]), and I found that mod_perl 1.28 doesn't work with it. (And that's without my patch -- just a plain mp1.28 straight out of the box.) It built OK (after I installed various prerequisites -- HTML-Tagset, HTML-Parser, libwin32, LWP, URI), but the test suite doesn't run at all. Manually running C:\apache\apache.exe -f C:\Temp\mod_perl-1.28\t\conf\httpd.conf -t just causes Windows to throw up an Application Error window. Once finished (should be soon) I will take care of all the outstanding issues, and there are quite a few. I apologize for not following up on those. No problem. Just wanted to check that it hadn't been forgotten. Steve
Re: Apache-print() problem with UTF-8 data in Perl 5.8
Randy Kobes wrote: On Tue, 29 Jul 2003, Steve Hay wrote: Is anybody going to take a serious look at the problem that I previously reported with Apache-print()'s handling of UTF-8 data in Perl 5.8? The patch that I sent (http://marc.theaimsgroup.com/?l=apache-modperlm=105912130001046w=2) seems to fix it for me on Windows as long as I've got perl #20203 incorporated. Does it work on other platforms? The #ifdef version-checks need a little work: on Windows (and other platforms [-- which ones?] that rely on Perl's makedef.pl to get symbols exported from the Perl library) you need perl-5.8.1; on other platforms the test for perl-5.8.0 should be fine. The brokenness of Apache-print() under perl-5.8.0 on Windows et al would also need documenting somewhere since it can't be fixed properly. Maybe it's just easier to change the version-checks to 5.8.1 for all platforms, and document the broken behaviour under 5.8.0? mod_perl 2 makes two special cases for handling systems that use export files - Win32 and aix ($^O eq 'aix'). So these might be the only two one has to worry about in this regard. These were the only two that Nicholas Clark mentioned when I asked about the missing PerlIO_isutf8() on the perl-xs list, so that may well be true. I will double-check with p5p to see if there are any more. I take it this is a problem in principle on all platforms running perl-5.8? Yes. If so, what might work is, for all platforms running 5.8.x, apply the patch, except for Win32 and aix (I'm not sure of aix), which would require 5.8.1. So something like #if PERL_VERSION = 8 #if ( defined(WIN32) || defined(_AIX) ) PERL_SUBVERSION = 1 #endif #endif And then, as you say, document the broken behaviour under Win32 (and aix?) for 5.8.0. I agree entirely with your sentiment, but shouldn't the logic be more like this: #if PERL_VERSION = 8 ((!defined(WIN32) !defined(_AIX)) || PERL_SUBVERSION = 1) ... #endif Steve
Re: Apache-print() problem with UTF-8 data in Perl 5.8
On Tue, 29 Jul 2003, Steve Hay wrote: [ .. ] I agree entirely with your sentiment, but shouldn't the logic be more like this: #if PERL_VERSION = 8 ((!defined(WIN32) !defined(_AIX)) || PERL_SUBVERSION = 1) ... #endif You're right - thanks. -- best regards, randy
OT: database table construction
I just got Practical mod_perl, and've been going through it. I also got MySQLby DuBois. Both of these books talk about speed and efficiency, but neither of them talk about designing the actual database tables to maximize speed. I have some rudimentary understanding, but I'm looking for more. Are there any books or URLs that folks would recommend? Thanks, Zack -- Zack Brown
Re: Working directory of script is / !
On Tue, 29 Jul 2003, ColinB wrote:
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 /.
Try the following, instead of ModPerl::RegistryCooker::chdir_file
above:
sub chdir_file_normal {
use File::Basename();
my $file = @_ == 2 ? $_[1] : $_[0]-{FILENAME};
my $dir = File::Basename::dirname($file);
chdir $dir or die Can't chdir to $dir: $!;
}
--
best regards,
randy kobes
[mp2 ANNOUNCE] Apache-ParseFormData-0.06 (new module)
I'm pleased to announce the release of Apache-ParseFormData-0.06, a replace for Apache::Request (libapreq). This module only work with mod_perl-2 and apache 2. http://search.cpan.org/author/HDIAS/Apache-ParseFormData-0.06/ParseFormData.pm Thanks, Henrique Dias -- Henrique Manuel Ribeiro Dias Escola Superior de Biotecnologia - UCP Gabinete de Desenvolvimento de Software Rua Dr. Antonio Bernardino de Almeida 4200 Porto Portugal Tel: 351-225580092 CPAN: http://www.cpan.org/authors/id/H/HD/HDIAS/
RE: Test unexpectedly succeeded during make test
Stas, I had an older version of CGI.pm. After installing the new module everything worked perfect. Thanks for you help! Ryan Laus -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2003 6:11 PM To: Laus, Ryan J. Cc: [EMAIL PROTECTED] Subject: Re: Test unexpectedly succeeded during make test Laus, Ryan J. wrote: Stas, Successfully installed LWP. So the filter/in_bbs_msg.t problem went away? I am receiving the following error when running make test cgiok 1/2# Failed test 2 in cgi.t at line 19 cgiFAILED test 2 Failed 1/2 tests, 50.00% okay Have you tried upgrading your CGI.pm? 2.93 or higher is required. The cvs version does that already. [Mon Jul 28 10:38:54 2003] [error] [client 127.0.0.1] File does not exist: /usr/ local/tmp/mod_perl-1.99_09/t/htdocs/registry/cgi.pl [...] I tried creating a directory under htdocs called registry and then copying the cgi.pl file into that directory just to see what would happen and both tests failed. no, no it's Location /registry, for some reason it can't find t/cgi-bin/cgi.pl, so it thinks that it might be a static file, t/htdocs/registry/cgi.pl which it's not. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Life of env vars set using Apache.pm-subprocess_env
Hi, Does apache clear env variables set by $r-subprocess_env() at the end of the request? Put in another way - Does apache start with a 'clean' environment for every request? Long description : - I set a bunch of variables in one the perl-handlers using Apache request object's $r-subprocess_env(). Do I need to unset these variables when I am done with the request? (or clear them always when I begin processing)? Assuming the same Apache thread/process is being used next time (serving a different client) and the code takes a different path, would there be any problems? Any help is appreciated. Thank you. -- Hari Bhaskaran
Re: Life of env vars set using Apache.pm-subprocess_env
Hari Bhaskaran wrote: Hi, Does apache clear env variables set by $r-subprocess_env() at the end of the request? sort of... Put in another way - Does apache start with a 'clean' environment for every request? that's a more accurate description :) --Geoff
Re: Working directory of script is / !
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, but that means that the same code won't work the same under threaded and non-threaded mpms. Hence the limbo. Still waiting for Arthur to finish porting safecwd package, which should resolve this problem. When he does finish it, won't we make the threaded MPM work just like this? It seems like it would be reasonable to get prefork working properly, even if the threaded MPM isn't ready yet. It's a tricky thing. If we do have a complete implementation then it's cool. If not then we have a problem with people testing their code on prefork mpm and then users getting the code malfunctioning on the threaded mpms. I think we could have a temporary subclass of the registry (e.g.: ModPerl::RegistryPrefork) which will be removed once the issue is resolved. At least it'll remind the developers that their code won't work on the threaded mpm setups. However if they make their code working without relying on chdir then they can use Modperl::Registry and the code will work everywhere. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Working directory of script is / !
Randy Kobes wrote:
On Tue, 29 Jul 2003, ColinB wrote:
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 /.
Try the following, instead of ModPerl::RegistryCooker::chdir_file
above:
sub chdir_file_normal {
use File::Basename();
my $file = @_ == 2 ? $_[1] : $_[0]-{FILENAME};
my $dir = File::Basename::dirname($file);
chdir $dir or die Can't chdir to $dir: $!;
}
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;
__END__
now configure it as before but use the package name ModPerl::RegistryPrefork;
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-print() problem with UTF-8 data in Perl 5.8
Steve Hay wrote: [...] Is there a problem with mod_perl 1.28 under the forthcoming perl 5.8.1 as well? I just tried out Jarkko's latest release (http://www.iki.fi/jhi/[EMAIL PROTECTED]), and I found that mod_perl 1.28 doesn't work with it. (And that's without my patch -- just a plain mp1.28 straight out of the box.) It built OK (after I installed various prerequisites -- HTML-Tagset, HTML-Parser, libwin32, LWP, URI), but the test suite doesn't run at all. Manually running C:\apache\apache.exe -f C:\Temp\mod_perl-1.28\t\conf\httpd.conf -t just causes Windows to throw up an Application Error window. Oh, that's bad. I didn't see any problems with linux with rc2. Now getting 20277, will test shortly again. make sure that jarkko knows about it and hopefully you and Randy can resolve it. Once finished (should be soon) I will take care of all the outstanding issues, and there are quite a few. I apologize for not following up on those. No problem. Just wanted to check that it hadn't been forgotten. No, no, all piled up in my modperl folders ;) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 ANNOUNCE] Apache-ParseFormData-0.06 (new module)
Henrique Dias wrote: I'm pleased to announce the release of Apache-ParseFormData-0.06, a replace for Apache::Request (libapreq). Cool. Though it's implemented in perl (==slower). Did you try to replicate it because of being frustrated of not having Apache::Request? Would be nice if the interested parties offer help to finish libapreq (on the apreq-dev list). And get_client_block() still has problems in the latest apache 2.0 :( This module only work with mod_perl-2 and apache 2. http://search.cpan.org/author/HDIAS/Apache-ParseFormData-0.06/ParseFormData.pm But I think your doc needs some more work as it says: my $apr = Apache::Request-new($r, disable_uploads = 1); ^^^ or is it on purpose as a drop-in replacement? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
privileged execution
I have a web application for that needs to execute a privileged command on its host for administrative purposes. Can someone suggest a good solution that will allow 'nobody' to execute the script command but still keep it secure from other users on the same host. Thanks. [EMAIL PROTECTED]
Re: privileged execution
Hello Michael, Wednesday, July 30, 2003, 7:32:23 AM, you wrote: M I have a web application for that needs to execute a privileged M command on its host for administrative purposes. Can someone suggest a M good solution that will allow 'nobody' to execute the script command M but still keep it secure from other users on the same host. M Thanks. M [EMAIL PROTECTED] You may start internal separate process with priveleges as required for your tasks and talk with him from apache unpriveleged process to do privileged job. -- WBR, Mike P. Mikhailov mailto: [EMAIL PROTECTED] ICQ:280990142 Just because something is obviously happening doesn't mean something obvious is happening.
