subject:"\[modperl\]"


Martin Langhoff writes:
   how can I restart the root httpd server from within modperl?
  
  Use `at` to schedule it a minute in the future -- effectively forking it.

Yes, also thought of that but the smallest unit of 'at' is minutes and
I want to restart the server immediately.

  Note that normally apache starts as root and runs as an unprivileged 
  user. If this is the case you _can_ achieve it using a suid wrapper or 
  sudo, but you'll risk opening a very serious security hole in the 
  system. So don't. Instead, run apache as a regular user, on a high port.

I used sudo.

Dirk

RE: HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)...

2003-08-14 Thread Steve Bannerman

Stas,

Replies below:
--
   Steve Bannerman
   [EMAIL PROTECTED]
   44.(0)1865.273866


 -Original Message-
 From: Stas Bekman [mailto:[EMAIL PROTECTED]
 Sent: 05 August 2003 18:07
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: HTTP POST: parameters empty when using ModPerl::Registry
 (okay when using ModPerl:PerlRun)...


  ...snip...
 

 The docs need work, this is just a copy of mp1 registry docs, which need
 adjustments. However most things work the same way. The
 differences between
 Registry and PerlRun are easily summarizes with this diff:

 ModPerl-Registry diff -u lib/ModPerl/Registry.pm lib/ModPerl/PerlRun.pm
 --- lib/ModPerl/Registry.pm 2003-03-22 20:52:24.0 -0800
 +++ lib/ModPerl/PerlRun.pm  2003-03-22 20:52:24.0 -0800
 @@ -1,4 +1,4 @@
 -package ModPerl::Registry;
 +package ModPerl::PerlRun;

   use strict;
   use warnings FATAL = 'all';
 @@ -30,11 +30,11 @@
   make_namespace  = 'make_namespace',
   namespace_root  = 'namespace_root',
   namespace_from  = 'namespace_from_filename',
 -is_cached   = 'is_cached',
 -should_compile  = 'should_compile_if_modified',
 -flush_namespace = 'NOP',
 +is_cached   = 'FALSE',
 +should_compile  = 'TRUE',
 +flush_namespace = 'flush_namespace_normal',
   cache_table = 'cache_table_common',
 -cache_it= 'cache_it',
 +cache_it= 'NOP',
   read_script = 'read_script',
   rewrite_shebang = 'rewrite_shebang',
   set_script_name = 'set_script_name',
 @@ -53,17 +53,10 @@

 PerlRun doesn't cache the script on each request and it flushes
 the script's
 namespace on each request. You can see the actual functions in
 lib/ModPerl/RegistryCooker.pm.

Thanks, that's helpful...it shows me why PerlRun works.

However, it doesn't really explain why the root problem exists.  The way I
think about it, the creation of a new CGI object should create a new set
of slots for instance data.  Then, each request's parameters would be
stored in a slot of the new CGI instance rather than in the global set of
slots for the class of CGI instances.

Maybe I don't understand the object paradigm in perl correctly; however, I
do understand it very well in general.  Thus, it seems like a defect in
either perl (the language) or CGI.pm.  I'm guessing there's some
justification for it in performance...however, it just doesn't seem right.

Thoughts?

 If you can try to take it from
 here and see
 what the problem is (your code/registry?), that would be cool. Thanks.


Unfortunately, I don't really know how to take it from here.  I'm pretty
new to perl and very new to mod_perl.  Thus I'm reaching out to you guys
to find out if anybody has solved this problem...unfortunately,
Christopher's suggestion didn't work (unless I implemented it incorrectly).

 Also make sure you are using the latest CGI.pm (2.93 or higher is good).

I'm using CGI.pm-2.98.

Cheers


 __
 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: How to restart the root server from within modperl?

2003-08-14 Thread Egor Shipovalov

In fact, I'm using 'killall httpd', which effectively kills every httpd
process. The drawback is that you need /proc available and that it may kill
httpd's belonging to another Apache.

But afrer all, you can always write awk script that would parse ps output
and do exactly what you want.

Egor.

 One word of caution; killing just the parent httpd process will likely
 cause a lot of zombie processes since the parent process has died and
 will not be available to receive SIGCHLD. I don't have a solution, just
 thought I would offer a possible symptom to look out for.



 On Tue, 2003-08-12 at 12:38, Egor Shipovalov wrote:
  Why not start the Apache from a shell script that would always start it
  again if it dies?
  To restart the Apache then, you'd just kill the root httpd with
 apachectl.
  Killing the paernt shell script would terminate the whole operation.
 
  Egor.
 
   -Original Message-
   From: Dirk Lutzebaeck [mailto:[EMAIL PROTECTED]
   Sent: Tuesday, August 12, 2003 1:17
   To: [EMAIL PROTECTED]
   Subject: How to restart the root server from within modperl?
  
  
  
   Hi,
  
   how can I restart the root httpd server from within modperl? My
   problem is that when I call system() with say apachectl restart the
   father process is stopped killing the children including the apachectl
   itself. So it can't start of again. Can I call something like a reload
   of httpd.conf?
  
   Why I want to do this? I have a set of configurations and file links
   for different versions for my modperl application which I
 want to activate
   from the modperl application itself (having a HTML user interface).
  
   Thanks for help,
  
   Dirk
 --

Re: How to restart the root server from within modperl?

2003-08-14 Thread Torsten Foertsch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tuesday 12 August 2003 11:50, Dirk Lutzebaeck wrote:
 Dennis Stout writes:
   On a whim, I would try writing a second script to do the actual shutdown
   and restart of Apache.
  
   Then have your mod_perl program either run it in the background (with a
   ) or fork it into another process.

 Did exactly that but is has the effect that when the parent (root)
 apache is killed it kills all children including the script itself. So
 the server wont start again.

I have done something like this several times. My code (it works since 1998 on 
a highly used WEB Server with perl5.005_3) looks like that:

...

sub sysclose {
  require 'syscall.ph';
  syscall SYS_close, shift()+0;
}

sub RLIMIT_NOFILE {7;}  # this is for LINUX
sub getrlimit {
  require 'syscall.ph';
  my $x=xx8;  # result
  syscall SYS_getrlimit, shift()+0, $x;
  unpack ii, $x;
}

sub close_fd {
  my @l=getrlimit( RLIMIT_NOFILE );
  my $l;

  for( $l=0; $l$l[0]; $l++ ) {
next if( $l==2 );   # close all file descriptors except of STDERR
sysclose $l;
  }
}

sub disconnect_from_apache {
  use POSIX qw/setsid/;

  setsid;
  close_fd;
}

...

my $child=fork;
unless( defined $child ) {
  ...
  return OK;
}
if( $child ) {
  my $child_status=0;
  if( waitpid( $child, 0 )==$child ) {
$child_status=$?;
  }

  if( $child_status==0 ) {
...
return OK;
  } else {
# The first fork succeeded but the second failed
...
return OK;
  }
} else {
  # Child process: fork again to detach from parent process
  $child=fork;
  CORE::exit( 0 ) if( $child ); # parent exits
  unless( defined $child ) {
...
CORE::exit( 1 );
  }
  # Now we are the 2nd child process.
  $self-disconnect_from_apache;
  $self-doit( ... );   # == here comes the real code
  CORE::exit( 0 );
}

...

$self-doit() is called in a separate process group and is not killed by a 
signal sent to the apache process group. Further, all files save STDERR are 
closed. This is needed since the code runs under mod_perl and the long 
running child process inherits the open connection to the browser. If this 
connection is not closed the browser shows an endless spinning globe or 
something like that in the upper right corner.

Torsten
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/OSIAwicyCTir8T4RAv3RAKCXdpbHLQepeOZFCyXt1KkMVGnwPgCeNu7X
hlC1NSEv0NsA7LlM7lol7wI=
=xId6
-END PGP SIGNATURE-

[Slightly OT] Port forwarding (Was: How to restart the root serverfrom within modperl?)

2003-08-14 Thread Andrew Ho

Hello,

MLIf you absolutely need to be in port 80, either setup a simple 
MLlightweight apache on port 80 as a reverse proxy (see the mod_perl 
MLguide) or, even simpler, do some port forwarding from port 80 to your 
MLhigh port of choice.

Has anybody had very good experiences using a simple port forwarder in a
production setup? We had a somewhat bad experience with using portfwd
under Solaris (images and other binary data got randomly corrupted, and we
never got around to figuring out why), and I'm wondering what others use
instead. It seems like the port forwarder involved would also be important
performance wise.

The applications I am typically interested in are forwarding ports on the
same interface (like the port 80 example here) as well as between
interfaces (or between external interfaces and loopback).

Humbly,

Andrew

--
Andrew Ho   http://www.tellme.com/   [EMAIL PROTECTED]
Engineer1-800-555-TELL  Voice 650-930-9062
Tellme Networks, Inc. Fax 650-930-9101
--

HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)...

2003-08-14 Thread Steve Bannerman

All,

I apologize if this has already been covered...I looked at the archives
since May but couldn't see anything covering this (there were related items
but their solutions didn't solve this problem).

Here an explanation of the problem:

We want to post experiment results to an upload server which is running
Apache HTTP Server (2.0.46) and mod_perl (1.99_09).  When we post a sequence
of files to the server, some of them are written to the local disk and some
are not.  That is, the test fails when using ModPerl::Registry but it
succeeds when using ModPerl::PerlRun.

In analyzing which ones work and which ones do not, I wrote a quick test to
see why the transfer is not working.  From the looks of the results, it
appears that the first request handled by a particular Apache process/thread
works and that any subsequent requests handled by that thread fail.
Works means that the file in the test gets saved to disk and fail means that
a file of size 0 gets written to disk.

Below are the httpd.conf segments (working and failing), the test client
(test_client.pl) and the test server (test_server.pl which is accessible
from the /cpdn/cgi-bin location).

Any suggestions?  Thanks in advance...

Also, does it matter if I use ModPerl::PerlRun instead of ModPerl::Registry
(I have read some about this at
http://apache.perl.org/docs/2.0/api/ModPerl/Registry.html but the
documentation there is a little light).

--
Working httpd.conf
--
Location /cpdn/cgi-bin
  AllowOverride None
  SetHandler perl-script
  PerlResponseHandler ModPerl::PerlRun
  PerlOptions +ParseHeaders
  Options +ExecCGI
  Allow from All
/Location

--
Failing httpd.conf
--
Location /cpdn/cgi-bin
  AllowOverride None
  SetHandler perl-script
  PerlResponseHandler ModPerl::Registry
  PerlOptions +ParseHeaders
  Options +ExecCGI
  Allow from All
/Location

--
test_client.pl
--
#!/usr/bin/perl
use strict;

use LWP::UserAgent;
use HTTP::Request::Common;

my $postUrl = $ARGV[0];
my $file = $ARGV[1];

my $postType = 'form-data';

my $ua = new LWP::UserAgent;
my $req = POST($postUrl,
   Content_Type = $postType,
   Content = [ file = [$file] ]);

my $res = $ua-request($req);
if ($res-is_success()) {
  print POST test successful\n;
  print $res-content();
} else {
  print STDERR POST test failed;
  print STDERR code:  . $res-code() . \n;
  print STDERR message:  . $res-message() . \n;
}

--
test_server.pl
--
use strict;
use CGI qw(:standard);

my $cgi = new CGI;
saveFile();

sub saveFile {
  my $inputfile = $cgi-param('file');
  my $outputfile = /tmp/file- . $$ . - . time();
  open(FILE,$outputfile) || printError();
  my $buffer;
  while (read($inputfile,$buffer,2096)) {
print FILE $buffer;
  }
  close(FILE);
  undef $buffer;
}

sub printError {
  print header();
  print Content-type: text/plain\n;
  print Status: 500$\n;
  print Message: Internal Error\n;
  exit;
}

Cheers
--
   Steve Bannerman
   [EMAIL PROTECTED]
   44.(0)1865.273866

Re: How to restart the root server from within modperl?


Thanks, I made it a bit more simple:

  use POSIX;

  if (! fork) { # child
 setsid;
 POSIX::close(0);
 POSIX::close(1);
 exec(restart-apache-command);
  }

Works great!

Thanks,

Dirk




Torsten Foertsch writes:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  On Tuesday 12 August 2003 11:50, Dirk Lutzebaeck wrote:
   Dennis Stout writes:
 On a whim, I would try writing a second script to do the actual shutdown
 and restart of Apache.

 Then have your mod_perl program either run it in the background (with a
 ) or fork it into another process.
  
   Did exactly that but is has the effect that when the parent (root)
   apache is killed it kills all children including the script itself. So
   the server wont start again.
  
  I have done something like this several times. My code (it works since 1998 on 
  a highly used WEB Server with perl5.005_3) looks like that:
  
  ...
  
  sub sysclose {
require 'syscall.ph';
syscall SYS_close, shift()+0;
  }
  
  sub RLIMIT_NOFILE {7;}   # this is for LINUX
  sub getrlimit {
require 'syscall.ph';
my $x=xx8;   # result
syscall SYS_getrlimit, shift()+0, $x;
unpack ii, $x;
  }
  
  sub close_fd {
my @l=getrlimit( RLIMIT_NOFILE );
my $l;
  
for( $l=0; $l$l[0]; $l++ ) {
  next if( $l==2 );# close all file descriptors except of STDERR
  sysclose $l;
}
  }
  
  sub disconnect_from_apache {
use POSIX qw/setsid/;
  
setsid;
close_fd;
  }
  
  ...
  
  my $child=fork;
  unless( defined $child ) {
...
return OK;
  }
  if( $child ) {
my $child_status=0;
if( waitpid( $child, 0 )==$child ) {
   $child_status=$?;
}
  
if( $child_status==0 ) {
  ...
   return OK;
} else {
   # The first fork succeeded but the second failed
  ...
   return OK;
}
  } else {
# Child process: fork again to detach from parent process
$child=fork;
CORE::exit( 0 ) if( $child ); # parent exits
unless( defined $child ) {
  ...
   CORE::exit( 1 );
}
# Now we are the 2nd child process.
$self-disconnect_from_apache;
$self-doit( ... );   # == here comes the real code
CORE::exit( 0 );
  }
  
  ...
  
  $self-doit() is called in a separate process group and is not killed by a 
  signal sent to the apache process group. Further, all files save STDERR are 
  closed. This is needed since the code runs under mod_perl and the long 
  running child process inherits the open connection to the browser. If this 
  connection is not closed the browser shows an endless spinning globe or 
  something like that in the upper right corner.
  
  Torsten
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.0.7 (GNU/Linux)
  
  iD8DBQE/OSIAwicyCTir8T4RAv3RAKCXdpbHLQepeOZFCyXt1KkMVGnwPgCeNu7X
  hlC1NSEv0NsA7LlM7lol7wI=
  =xId6
  -END PGP SIGNATURE-

RE: How to restart the root server from within modperl?

2003-08-14 Thread Egor Shipovalov

 Can I call something like a reload of httpd.conf?

This is what sending a SIGHUP to Apache does. However, both mod_perl-enabled
servers I run misbehave on this, so I always do a full restart.

Egor.

Re: How to restart the root server from within modperl?

2003-08-14 Thread Martin Langhoff

how can I restart the root httpd server from within modperl?

Use `at` to schedule it a minute in the future -- effectively forking it.

Note that normally apache starts as root and runs as an unprivileged 
user. If this is the case you _can_ achieve it using a suid wrapper or 
sudo, but you'll risk opening a very serious security hole in the 
system. So don't. Instead, run apache as a regular user, on a high port.

If you absolutely need to be in port 80, either setup a simple 
lightweight apache on port 80 as a reverse proxy (see the mod_perl 
guide) or, even simpler, do some port forwarding from port 80 to your 
high port of choice.

regards,



martin

Re: [Slightly OT] Port forwarding (Was: How to restart the root serverfrom within modperl?)

2003-08-14 Thread Craig Edwards

Hi, 
I once saw an example of port forwarding using netcat and inetd, i think it involved 
setting up a listening netcat as the application, using inetd to bind it to a specific 
port and then forwarding the connection onwards to the ip and/or port where you want 
it to go, something like this:

service geofwd  
{  
   flags = REUSE  
   socket_type = stream  
   wait = no  
   user = root  
   server = /usr/bin/nc  
   server_args = 192.168.124.38 1005  
   log_on_failure += USERID  
} 


not sure if this is what you want :-)

Craig

Hello,

MLIf you absolutely need to be in port 80, either setup a simple 
MLlightweight apache on port 80 as a reverse proxy (see the mod_perl 
MLguide) or, even simpler, do some port forwarding from port 80 to your 
MLhigh port of choice.

Has anybody had very good experiences using a simple port forwarder in a
production setup? We had a somewhat bad experience with using portfwd
under Solaris (images and other binary data got randomly corrupted, and we
never got around to figuring out why), and I'm wondering what others use
instead. It seems like the port forwarder involved would also be important
performance wise.

The applications I am typically interested in are forwarding ports on the
same interface (like the port 80 example here) as well as between
interfaces (or between external interfaces and loopback).

Humbly,

Andrew

--
Andrew Ho   http://www.tellme.com/   [EMAIL PROTECTED]
Engineer1-800-555-TELL  Voice 650-930-9062
Tellme Networks, Inc. Fax 650-930-9101
--

How to restart the root server from within modperl?


Hi,

how can I restart the root httpd server from within modperl? My
problem is that when I call system() with say apachectl restart the
father process is stopped killing the children including the apachectl
itself. So it can't start of again. Can I call something like a reload
of httpd.conf?

Why I want to do this? I have a set of configurations and file links
for different versions for my modperl application which I want to activate
from the modperl application itself (having a HTML user interface).

Thanks for help,

Dirk

RE: How to restart the root server from within modperl?

2003-08-14 Thread Egor Shipovalov

Why not start the Apache from a shell script that would always start it
again if it dies?
To restart the Apache then, you'd just kill the root httpd with apachectl.
Killing the paernt shell script would terminate the whole operation.

Egor.

 -Original Message-
 From: Dirk Lutzebaeck [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, August 12, 2003 1:17
 To: [EMAIL PROTECTED]
 Subject: How to restart the root server from within modperl?



 Hi,

 how can I restart the root httpd server from within modperl? My
 problem is that when I call system() with say apachectl restart the
 father process is stopped killing the children including the apachectl
 itself. So it can't start of again. Can I call something like a reload
 of httpd.conf?

 Why I want to do this? I have a set of configurations and file links
 for different versions for my modperl application which I want to activate
 from the modperl application itself (having a HTML user interface).

 Thanks for help,

 Dirk

Re: How to restart the root server from within modperl?


Dennis Stout writes:
  On a whim, I would try writing a second script to do the actual shutdown and
  restart of Apache.
  
  Then have your mod_perl program either run it in the background (with a ) or
  fork it into another process.

Did exactly that but is has the effect that when the parent (root)
apache is killed it kills all children including the script itself. So
the server wont start again.

Dirk

[mp2] ModPerl::Test::read_post destructive?

2003-08-14 Thread Michael Maciag

Apache/2.0.44 (Unix) mod_perl/1.99_09 Perl/v5.8.0

Using a copy of the read_post routine, I'm able to retrieve my POST
parameters reliably from my PerlResponseHandler. However, it seems when I do
invoke that routine, the client no longer receives the parameters. If I just
comment out my invocation of read_post, the client once again receives the
POST parameters.

Is the read_post in ModPerl::Test destructive in some way? If so, could
someone point me in the right direction I might take to modify it to be
non-destructive?

- Mike.

RE: [mp2] ModPerl::Test::read_post destructive?

2003-08-14 Thread Michael Maciag

Yikes, you're right! I just found a recent thread in the apache dev list
discussing this.

Thanks, I'll approach my problem another way.

- Mike.

-Original Message-
From: Ged Haywood [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 10, 2003 12:47 PM
To: Michael Maciag
Cc: Modperl Mailing List
Subject: Re: [mp2] ModPerl::Test::read_post destructive?


Hi there,

On Sun, 10 Aug 2003, Michael Maciag wrote:

 Is the read_post in ModPerl::Test destructive in some way? If so, could
 someone point me in the right direction I might take to modify it to be
 non-destructive?

I think you'll find that reading POST data has always been destructive.
If you want to read it more than once you have to save it somewhere.
Check the archives for more information.

73,
Ged.

Re: HTTP POST: parameters empty when using ModPerl::Registry (okaywhen using ModPerl:PerlRun)...

2003-08-14 Thread Stas Bekman

Steve Bannerman wrote:
All,

I apologize if this has already been covered...I looked at the archives
since May but couldn't see anything covering this (there were related items
but their solutions didn't solve this problem).
Here an explanation of the problem:

We want to post experiment results to an upload server which is running
Apache HTTP Server (2.0.46) and mod_perl (1.99_09).  When we post a sequence
of files to the server, some of them are written to the local disk and some
are not.  That is, the test fails when using ModPerl::Registry but it
succeeds when using ModPerl::PerlRun.
In analyzing which ones work and which ones do not, I wrote a quick test to
see why the transfer is not working.  From the looks of the results, it
appears that the first request handled by a particular Apache process/thread
works and that any subsequent requests handled by that thread fail.
Works means that the file in the test gets saved to disk and fail means that
a file of size 0 gets written to disk.
Below are the httpd.conf segments (working and failing), the test client
(test_client.pl) and the test server (test_server.pl which is accessible
from the /cpdn/cgi-bin location).
Any suggestions?  Thanks in advance...

Also, does it matter if I use ModPerl::PerlRun instead of ModPerl::Registry
(I have read some about this at
http://apache.perl.org/docs/2.0/api/ModPerl/Registry.html but the
documentation there is a little light).
The docs need work, this is just a copy of mp1 registry docs, which need 
adjustments. However most things work the same way. The differences between 
Registry and PerlRun are easily summarizes with this diff:

ModPerl-Registry diff -u lib/ModPerl/Registry.pm lib/ModPerl/PerlRun.pm
--- lib/ModPerl/Registry.pm 2003-03-22 20:52:24.0 -0800
+++ lib/ModPerl/PerlRun.pm  2003-03-22 20:52:24.0 -0800
@@ -1,4 +1,4 @@
-package ModPerl::Registry;
+package ModPerl::PerlRun;
 use strict;
 use warnings FATAL = 'all';
@@ -30,11 +30,11 @@
 make_namespace  = 'make_namespace',
 namespace_root  = 'namespace_root',
 namespace_from  = 'namespace_from_filename',
-is_cached   = 'is_cached',
-should_compile  = 'should_compile_if_modified',
-flush_namespace = 'NOP',
+is_cached   = 'FALSE',
+should_compile  = 'TRUE',
+flush_namespace = 'flush_namespace_normal',
 cache_table = 'cache_table_common',
-cache_it= 'cache_it',
+cache_it= 'NOP',
 read_script = 'read_script',
 rewrite_shebang = 'rewrite_shebang',
 set_script_name = 'set_script_name',
@@ -53,17 +53,10 @@
PerlRun doesn't cache the script on each request and it flushes the script's 
namespace on each request. You can see the actual functions in 
lib/ModPerl/RegistryCooker.pm. If you can try to take it from here and see 
what the problem is (your code/registry?), that would be cool. Thanks.

Also make sure you are using the latest CGI.pm (2.93 or higher is good).

__
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[2]: How to restart the root server from within modperl?

2003-08-12 Thread Mike P. Mikhailov

Hello Dirk Lutzebaeck,

Tuesday, August 12, 2003, 3:50:01 PM, you wrote:


DL Dennis Stout writes:
DL   On a whim, I would try writing a second script to do the actual shutdown and
DL   restart of Apache.
DL   
DL   Then have your mod_perl program either run it in the background (with a ) or
DL   fork it into another process.

DL Did exactly that but is has the effect that when the parent (root)
DL apache is killed it kills all children including the script itself. So
DL the server wont start again.

DL Dirk

Try double fork. I'm used this approach to start long running job.
Job must be done even apache process die. So they completly detached
from parent apache process.

Read this, I hope this relevant

http://perl.apache.org/docs/1.0/guide/performance.html#Avoiding_Zombie_Processes

-- 
WBR, Mike P. Mikhailov

mailto: [EMAIL PROTECTED]
ICQ:280990142

If you put three drops of poison into a 100 percent pure Java, you get - Windows.
If you put a few drops of Java into Windows, you still have Windows.

Re: [mp2] ModPerl::Test::read_post destructive?

2003-08-10 Thread Ged Haywood

Hi there,

On Sun, 10 Aug 2003, Michael Maciag wrote:

 Is the read_post in ModPerl::Test destructive in some way? If so, could
 someone point me in the right direction I might take to modify it to be
 non-destructive?

I think you'll find that reading POST data has always been destructive.
If you want to read it more than once you have to save it somewhere.
Check the archives for more information.

73,
Ged.

RE: HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)...

2003-08-06 Thread Christopher Knight

try
CGI-initialize_globals();
at the begining of the script but before you use params

if you are depending on the 'use CGI' statement to initialize your params (like a 
command line script), it will cause
problems in Registry.  Thats becuase it is initialized once on the initial 'use CGI' 
and it stays in memory for the life
of the webserver.  So each time you use a script, you have to initialize the CGI 
params to your current request.

-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 05, 2003 12:07 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: HTTP POST: parameters empty when using ModPerl::Registry
(okay when using ModPerl:PerlRun)...


Steve Bannerman wrote:
 All,

 I apologize if this has already been covered...I looked at the archives
 since May but couldn't see anything covering this (there were related items
 but their solutions didn't solve this problem).

 Here an explanation of the problem:

 We want to post experiment results to an upload server which is running
 Apache HTTP Server (2.0.46) and mod_perl (1.99_09).  When we post a sequence
 of files to the server, some of them are written to the local disk and some
 are not.  That is, the test fails when using ModPerl::Registry but it
 succeeds when using ModPerl::PerlRun.

 In analyzing which ones work and which ones do not, I wrote a quick test to
 see why the transfer is not working.  From the looks of the results, it
 appears that the first request handled by a particular Apache process/thread
 works and that any subsequent requests handled by that thread fail.
 Works means that the file in the test gets saved to disk and fail means that
 a file of size 0 gets written to disk.

 Below are the httpd.conf segments (working and failing), the test client
 (test_client.pl) and the test server (test_server.pl which is accessible
 from the /cpdn/cgi-bin location).

 Any suggestions?  Thanks in advance...

 Also, does it matter if I use ModPerl::PerlRun instead of ModPerl::Registry
 (I have read some about this at
 http://apache.perl.org/docs/2.0/api/ModPerl/Registry.html but the
 documentation there is a little light).

The docs need work, this is just a copy of mp1 registry docs, which need
adjustments. However most things work the same way. The differences between
Registry and PerlRun are easily summarizes with this diff:

ModPerl-Registry diff -u lib/ModPerl/Registry.pm lib/ModPerl/PerlRun.pm
--- lib/ModPerl/Registry.pm 2003-03-22 20:52:24.0 -0800
+++ lib/ModPerl/PerlRun.pm  2003-03-22 20:52:24.0 -0800
@@ -1,4 +1,4 @@
-package ModPerl::Registry;
+package ModPerl::PerlRun;

  use strict;
  use warnings FATAL = 'all';
@@ -30,11 +30,11 @@
  make_namespace  = 'make_namespace',
  namespace_root  = 'namespace_root',
  namespace_from  = 'namespace_from_filename',
-is_cached   = 'is_cached',
-should_compile  = 'should_compile_if_modified',
-flush_namespace = 'NOP',
+is_cached   = 'FALSE',
+should_compile  = 'TRUE',
+flush_namespace = 'flush_namespace_normal',
  cache_table = 'cache_table_common',
-cache_it= 'cache_it',
+cache_it= 'NOP',
  read_script = 'read_script',
  rewrite_shebang = 'rewrite_shebang',
  set_script_name = 'set_script_name',
@@ -53,17 +53,10 @@

PerlRun doesn't cache the script on each request and it flushes the script's
namespace on each request. You can see the actual functions in
lib/ModPerl/RegistryCooker.pm. If you can try to take it from here and see
what the problem is (your code/registry?), that would be cool. Thanks.

Also make sure you are using the latest CGI.pm (2.93 or higher is good).

__
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: HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)...

2003-08-06 Thread Steve Bannerman

Christopher,

Thanks for the suggestion; unfortunately, it doesn't work.  I made the
change you suggested (inserting CGI-initialize_globals(); just before
creating an instance of CGI) and restarted apache/httpd.  The same
result...the first time the script executes it saves the file
properly...after that, a file is created with 0 size.

Besides, as you (and others prescribing the use of initialize_globals())
described it, shouldn't subsequent executions of the script write the same
file as the first execution.  That is, if the parameters of the CGI
instances are actually global, wouldn't the same array of bytes still be in
the global 'file' parameter?

Cheers
--
   Steve Bannerman
   [EMAIL PROTECTED]
   44.(0)1865.273866


 -Original Message-
 From: Christopher Knight [mailto:[EMAIL PROTECTED]
 Sent: 05 August 2003 18:20
 To: Stas Bekman; [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: RE: HTTP POST: parameters empty when using ModPerl::Registry
 (okay when using ModPerl:PerlRun)...


 try
 CGI-initialize_globals();
 at the begining of the script but before you use params

 if you are depending on the 'use CGI' statement to initialize
 your params (like a command line script), it will cause
 problems in Registry.  Thats becuase it is initialized once on
 the initial 'use CGI' and it stays in memory for the life
 of the webserver.  So each time you use a script, you have to
 initialize the CGI params to your current request.

 -Original Message-
 From: Stas Bekman [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, August 05, 2003 12:07 PM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: HTTP POST: parameters empty when using ModPerl::Registry
 (okay when using ModPerl:PerlRun)...


 Steve Bannerman wrote:
  All,
 
  I apologize if this has already been covered...I looked at the archives
  since May but couldn't see anything covering this (there were
 related items
  but their solutions didn't solve this problem).
 
  Here an explanation of the problem:
 
  We want to post experiment results to an upload server which
 is running
  Apache HTTP Server (2.0.46) and mod_perl (1.99_09).  When we
 post a sequence
  of files to the server, some of them are written to the local
 disk and some
  are not.  That is, the test fails when using ModPerl::Registry but it
  succeeds when using ModPerl::PerlRun.
 
  In analyzing which ones work and which ones do not, I wrote a
 quick test to
  see why the transfer is not working.  From the looks of the results, it
  appears that the first request handled by a particular Apache
 process/thread
  works and that any subsequent requests handled by that thread fail.
  Works means that the file in the test gets saved to disk and
 fail means that
  a file of size 0 gets written to disk.
 
  Below are the httpd.conf segments (working and failing), the test client
  (test_client.pl) and the test server (test_server.pl which is accessible
  from the /cpdn/cgi-bin location).
 
  Any suggestions?  Thanks in advance...
 
  Also, does it matter if I use ModPerl::PerlRun instead of
 ModPerl::Registry
  (I have read some about this at
  http://apache.perl.org/docs/2.0/api/ModPerl/Registry.html but the
  documentation there is a little light).

 The docs need work, this is just a copy of mp1 registry docs, which need
 adjustments. However most things work the same way. The
 differences between
 Registry and PerlRun are easily summarizes with this diff:

 ModPerl-Registry diff -u lib/ModPerl/Registry.pm lib/ModPerl/PerlRun.pm
 --- lib/ModPerl/Registry.pm 2003-03-22 20:52:24.0 -0800
 +++ lib/ModPerl/PerlRun.pm  2003-03-22 20:52:24.0 -0800
 @@ -1,4 +1,4 @@
 -package ModPerl::Registry;
 +package ModPerl::PerlRun;

   use strict;
   use warnings FATAL = 'all';
 @@ -30,11 +30,11 @@
   make_namespace  = 'make_namespace',
   namespace_root  = 'namespace_root',
   namespace_from  = 'namespace_from_filename',
 -is_cached   = 'is_cached',
 -should_compile  = 'should_compile_if_modified',
 -flush_namespace = 'NOP',
 +is_cached   = 'FALSE',
 +should_compile  = 'TRUE',
 +flush_namespace = 'flush_namespace_normal',
   cache_table = 'cache_table_common',
 -cache_it= 'cache_it',
 +cache_it= 'NOP',
   read_script = 'read_script',
   rewrite_shebang = 'rewrite_shebang',
   set_script_name = 'set_script_name',
 @@ -53,17 +53,10 @@

 PerlRun doesn't cache the script on each request and it flushes
 the script's
 namespace on each request. You can see the actual functions in
 lib/ModPerl/RegistryCooker.pm. If you can try to take it from here and see
 what the problem is (your code/registry?), that would be cool. Thanks.

 Also make sure you are using the latest CGI.pm (2.93 or higher is good).

 __
 Stas BekmanJAm_pH -- Just Another mod_perl Hacker
 http://stason.org/ mod_perl Guide --- http

ModPerl - CGI in the same request phase

2003-08-06 Thread csebe

Hi again everybody,

I have the following interesting (I hope ;-) requirement. Sorry for this
rather long posting.
(mod_perl 1, Apache 1.3.27)

I have a custom authentication  authorization handler of mine which is the
king in a protected directory (and its subdirectories):

PerlModule MyModules::Module1
Directory /usr/local/apache1/protected
SetHandler perl-script
PerlHandler MyModules::Module1
PerlSendHeader Off
/Directory

Then, for some users that I authenticate as SuperUsers, I should allow the
execution of the administrative .cgi scripts in a subdir of this
dir(/usr/local/apache1/ssl/protected/admin).

(One solution would be to integrate the cgi-s logic into my handler but
let's say want to leave them as simple CGI scripts.)

I tried to use the Apache::PerlRun in the subdir like this:
PerlModule Apache::PerlRun
Directory /usr/local/apache1/protected/admin
SetHandler perl-script
PerlHandler Apache::PerlRun
PerlSendHeader On
Options ExecCGI
/Directory

I tried also:
Directory /usr/local/apache1/ssl/protected/admin
SetHandler cgi-script
Options +ExecCGI
/Directory

The problem is it allows anybody to execute the cgi's since it's not going
through my handler anymore (a warn ... statement inserted in my handler
shows it's not executed when requesting /protected/admin/* files.)

More generally: how can I dynamically change a directory's handler during
the same phase

I was thinking about using dynamic stacked handlers, something like: if the
user is allowed in the admin section, my handler should push the cgi-script
handler in the line of execution. However, the documentation says about
stacking more custom created handlers and not those coming with Apache so
I'm not sure how to do it.

Thanks for your time,

Lian Sebe, M.Sc.
Freelance Analyst-Programmer
www.programEz.net

RE: HTTP POST: parameters empty when using ModPerl::Registry(okay when using ModPerl:PerlRun)...

2003-08-06 Thread Perrin Harkins

On Wed, 2003-08-06 at 04:50, Steve Bannerman wrote:
 However, it doesn't really explain why the root problem exists.  The way I
 think about it, the creation of a new CGI object should create a new set
 of slots for instance data.

That would make sense, but very little about CGI.pm actually works in
the way you would expect.  It's a very bizarre module because of the
dual functional and object interface, and it uses lots of globals even
if you are only calling the OO interface.  If possible, I would suggest
you consider using CGI::Simple instead, which is a drop-in replacement.

 Maybe I don't understand the object paradigm in perl correctly; however, I
 do understand it very well in general.  Thus, it seems like a defect in
 either perl (the language) or CGI.pm.

It's a problem with CGI.pm, not with your understanding of Perl OO.

I believe I see the source of your troubles in the code that you
posted.  You are creating a closure by using a lexical variable and then
accessing it from within a sub.  This is a no-no with any long-running
system like mod_perl.  You can get away with it in a standard CGI
environment (or PerlRun) because it just exits after each request
instead of running the same code again.

Here is the offending section:

my $cgi = new CGI;
saveFile();

sub saveFile {
  my $inputfile = $cgi-param('file');
... etc ...
}

Change it to this:

my $cgi = new CGI;
saveFile($cgi);

sub saveFile {
  my $cgi = shift;
  my $inputfile = $cgi-param('file');
... etc ...
}

I think that will do it.

- Perrin

Re: AW: Apache:AuthenNTLM 2.01 with modperl 1.26

2003-07-23 Thread Shannon Eric Peevey

Tresp, Wilfried wrote:

Hi,

works now, thanks, next I'll try it with Apache2. AuthenNTLM was the only reason I have not tried it yet :)

Regards, Wilfried

-Ursprüngliche Nachricht-
Von: Shannon Eric Peevey [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 23. Juli 2003 20:50
An: Tresp, Wilfried
Betreff: Re: Apache:AuthenNTLM 2.01 with modperl 1.26
Tresp, Wilfried wrote:

Hello Shannon Eric,

as far as I understood the changes between Apache::AuthenNTLM 2.01 and the
older 0.23 from Gerald Richter your enhancements should make it possible to
use the modul with modperl 1.26 and modperl 2 also, is this right?
I tried to install your version with Apache 1.26, mod_perl 1.27 running
Solaris 8 with Perl 5.6.1 but every time a page is called which requires
authentication I get an internal Server Error and the error_log shows the
following entry:
[Wed Jul 23 20:12:36 2003] [error] Can't locate object method log via
package Apache (perhaps you forgot to load Apac
he?) at
/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/Apache/AuthenNTLM.pm line
598.
Do you know what happens?

Regards,

Wilfried Tresp

Hi!

Try this file. Just replace your AuthenNTLM.pm file that the install
placed in your perl modules directory with this one. It seems that
there was a problem here:

if ($type == 1)
{
597 --# my $log = $r-log;
my $nonce = $self - get_nonce ($r) ;
in the first handler subroutine at line 597... I have commented out the
line, and it should work now.

Thanks for the heads-up :)

speeves
cws

Great!!! I will upload a fixed version to CPAN, and it should be
available after a few hours.

speeves
cws

Re: AW: AW: Apache:AuthenNTLM 2.01 with modperl 1.26

2003-07-23 Thread Shannon Eric Peevey

Tresp, Wilfried wrote:

Hi Shannon Eric,

fine it's already there. I try to run the module with Apache 2.0.47 but it
didn't work here. There seems to be problems with my @INC variable but I can
not figure out how to fix it. When I try to start the daemon I see only the
following error message:
# /usr/local/apache2/bin/apachectl start
[Thu Jul 24 01:27:30 2003] [error] Can't locate Apache/AuthenSmb.pm in @INC
(@INC contains: /usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/Apache2
./Apache2 /usr/local/lib/perl5/5.6.1/sun4-solaris /usr/local/lib/perl5/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris
/usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl .
/usr/local/apache2/ /usr/local/apache2/lib/perl) at (eval 4) line 3.
[Thu Jul 24 01:27:30 2003] [error] Can't load Perl module Apache::AuthenSmb
for server netweb.de.kworld.kpmg.com:8000, exiting...
The module AuthenSmb.pm doesn't exist but I can not locate the problem. Do
you have any hints for me?
 

Hi!

Looks to me like you are trying to load Michael Parker's 
Apache::AuthenSmb module...  I don't believe that that mod is ported to 
mp2.   The Authen::Smb module is included with the Apache::AuthenNTLM 
module, so should have been installed when you ran the script.  If you 
change the module that you are trying to load Apache::AuthenNTLM, does 
that help?

speeves
cws
PS  Can you reply to the modperl mailing list?  Thanks :)

Re: AW: AW: Apache:AuthenNTLM 2.01 with modperl 1.26

2003-07-23 Thread Shannon Eric Peevey

Tresp, Wilfried wrote:

Hi Shannon Eric,

forget my last mail. It is simply to late. After changing PerlModule to
PerlResponseHandler in httpd.conf everything works now. Great!
Only little problem is that I see many error_log entries like the following:

[12163] the $self-{smbhandle} is 903424

ntlmdebug is set to 0

Maybe the line 198 of AuthenNTLM.pm is the reason for this:

   print STDERR [$$] the \$self-{smbhandle} is $self-{smbhandle}\n;

Regards,	Wilfried

 

Hi!

Glad that it's working now :)  The entries in the error log are just my 
debugging crap that I was using when I was porting.  I will clean up the 
code a little more and upload a new version tomorrow.

Thanks for all of your input!!!
speeves
cws

Re: ModPerl debugging

2003-07-14 Thread Stas Bekman

Christopher Knight wrote:
Im getting an error with ModPerl::Registry and ModPerl::PerlRun (I tried
both just in case)(that doesnt happen under CGI) that tells me I have an
errror...  (ya... that is about how usefull it is)
###SNIP###
[Tue Jun 24 08:15:58 2003] [error] 16728: ModPerl::PerlRun: Not a CODE
reference at /path/to/my/webserver/html/index.pl line 65.
[Tue Jun 24 08:16:26 2003] [error] [client .] Deep recursion on
subroutine ModPerl::RegistryCooker::default_handler at
/usr/local/lib/perl/5.6.1/ModPerl/PerlRun.pm line 16.
#
the problem is, its not giving me any usefull information as to where the
problem is... Considering I having about 10 custom modules that the script
calls on, I dont have enough time to look at every line of code.  Is there
anyway to turn on super-debug mode... etc... so I can get more info?
sure, set  MOD_PERL_TRACE/PerlTrace to 'h'

http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlTrace_

Also if you can submit a short example that reproduces the problem I can look 
at it.

__
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

ModPerl debugging

2003-06-24 Thread Christopher Knight

Im getting an error with ModPerl::Registry and ModPerl::PerlRun (I tried
both just in case)(that doesnt happen under CGI) that tells me I have an
errror...  (ya... that is about how usefull it is)

###SNIP###
[Tue Jun 24 08:15:58 2003] [error] 16728: ModPerl::PerlRun: Not a CODE
reference at /path/to/my/webserver/html/index.pl line 65.

[Tue Jun 24 08:16:26 2003] [error] [client .] Deep recursion on
subroutine ModPerl::RegistryCooker::default_handler at
/usr/local/lib/perl/5.6.1/ModPerl/PerlRun.pm line 16.
#

the problem is, its not giving me any usefull information as to where the
problem is... Considering I having about 10 custom modules that the script
calls on, I dont have enough time to look at every line of code.  Is there
anyway to turn on super-debug mode... etc... so I can get more info?

Thanks
Chris

Re: modperl 2.0: apache crashes when running modperl script

2003-06-05 Thread arunappa

Stas Bekman [EMAIL PROTECTED] wrote:


'make install' after you have rebuilt mod_perl with MP_DEBUG=1? try to nuke
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/Apache
and 'make install' again.

Actually I know why this happens and why you have the segfault

since you have had:

MP_INST_APACHE2 = 1

it must be installed into 
i686-linux-thread-multi/Apache2/auto/Apache/RequestIO/RequestIO.so

You probably had an older mod_perl install, and now it loads the wrong 
library. I see that you didn't load Apache2 and that explains the problem.

Add to your startup 'use Apache2' as explained here:
http://perl.apache.org/docs/2.0/user/intro/start_fast.html#Configuration


I removed RequestIO.so inside 
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/Apache
and did 'make install'. Then added 'use Apache2' in the startup file
and there are no segfaults anymore.

Thanks,

Natarajan Murugaiyan(Ravi)

__
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

Re: modperl 2.0: apache crashes when running modperl script

2003-06-04 Thread arunappa


-8-- Start Bug Report 8--
1. Problem Description:

apache crashes when accessing this modperl script:

package Apache::hello;

use strict;

use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::Const -compile = 'OK';

sub handler {
  my $request = shift;  # what does shift operate on @_?
  $request-content_type('text/html');

  $request-print(END);
HTML
BODY
H1Hello There/H1
/BODY
/HTML
END

return Apache::OK;
}





2. Used Components and their Configuration:

*** using /usr/download/modperl/mod_perl-1.99_09/t/../lib/Apache/BuildConfig.pm
*** Makefile.PL options:
  MP_AP_PREFIX= /usr/httpd20
  MP_COMPAT_1X= 1
  MP_GENERATE_XS  = 1
  MP_INST_APACHE2 = 1
  MP_LIBNAME  = mod_perl
  MP_USE_DSO  = 1
  MP_USE_STATIC   = 1


*** /usr/httpd20/bin/httpd -V
Server version: Apache/2.0.46
Server built:   Jun  1 2003 19:52:02
Server's Module Magic Number: 20020903:3
Architecture:   32-bit
Server compiled with
 -D APACHE_MPM_DIR=server/mpm/prefork
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D HTTPD_ROOT=/usr/httpd20
 -D SUEXEC_BIN=/usr/httpd20/bin/suexec
 -D DEFAULT_PIDLOG=logs/httpd.pid
 -D DEFAULT_SCOREBOARD=logs/apache_runtime_status
 -D DEFAULT_LOCKFILE=logs/accept.lock
 -D DEFAULT_ERRORLOG=logs/error_log
 -D AP_TYPES_CONFIG_FILE=conf/mime.types
 -D SERVER_CONFIG_FILE=conf/httpd.conf


*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
osname=linux, osvers=2.4.18-11smp, archname=i386-linux-thread-multi
uname='linux daffy.perf.redhat.com 2.4.18-11smp #1 smp thu aug 15 06:41:59 edt 
2002 i686 i686 i386 gnulinux '
config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dmyhostname=localhost 
[EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr 
-Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads 
-Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm 
-Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 
-Uversiononly -Dpager=/usr/bin/less -isr'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -march=i386 -mcpu=i686',
cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/include/gdbm'
ccversion='', gccversion='3.2 20020822 (Red Hat Linux Rawhide 3.2-5)', 
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
  Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil
libc=/lib/libc-2.2.92.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.2.92'
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic 
-Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl): 
  Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
  Built under linux
  Compiled at Sep  1 2002 23:56:49
  %ENV:
PERL_LWP_USE_HTTP_10=1
  @INC:
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
.


3. This is the core dump trace: (if you get a core dump):

I was able to run 'httpd -X' from inside gbd and got a stack trace
with mod_perl compiled with MP_DEBUG=1:

0x402f458c in modperl_wbucket_write (my_perl=0x81af228, wb=0x81b3900,
buf=0xb438 4, wlen=0x4063cb8f) at modperl_filter.c:181
181 *wlen = 0;

#0  0x402f458c in modperl_wbucket_write (my_perl=0x81af228, wb=0x81b3900,
buf=0xb438 4, wlen=0x4063cb8f) at modperl_filter.c:181
#1  0x40640701 in mpxs_Apache__RequestRec_print ()
   from 
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/Apache/RequestIO

Re: modperl 2.0: apache crashes when running modperl script

2003-06-04 Thread Stas Bekman

[EMAIL PROTECTED] wrote:
[...]
3. This is the core dump trace: (if you get a core dump):

I was able to run 'httpd -X' from inside gbd and got a stack trace
with mod_perl compiled with MP_DEBUG=1:
0x402f458c in modperl_wbucket_write (my_perl=0x81af228, wb=0x81b3900,
buf=0xb438 4, wlen=0x4063cb8f) at modperl_filter.c:181
181 *wlen = 0;
#0  0x402f458c in modperl_wbucket_write (my_perl=0x81af228, wb=0x81b3900,
buf=0xb438 4, wlen=0x4063cb8f) at modperl_filter.c:181
#1  0x40640701 in mpxs_Apache__RequestRec_print ()
   from 
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/Apache/RequestIO/RequestIO.so
#2  0x4063e8c6 in XS_Apache__RequestRec_print ()
   from 
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/Apache/RequestIO/RequestIO.so
why RequestIO.so doesn't include the debug info? Are you sure you have run 
'make install' after you have rebuilt mod_perl with MP_DEBUG=1? try to nuke
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/Apache
and 'make install' again.

Actually I know why this happens and why you have the segfault

since you have had:

MP_INST_APACHE2 = 1

it must be installed into 
i686-linux-thread-multi/Apache2/auto/Apache/RequestIO/RequestIO.so

You probably had an older mod_perl install, and now it loads the wrong 
library. I see that you didn't load Apache2 and that explains the problem.

Add to your startup 'use Apache2' as explained here:
http://perl.apache.org/docs/2.0/user/intro/start_fast.html#Configuration


__
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: modperl 2.0: apache crashes when running modperl script

2003-06-03 Thread arunappa

-8-- Start Bug Report 8--
1. Problem Description:

apache crashes when accessing this modperl script:

package Apache::hello;

use strict;

use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::Const -compile = 'OK';

sub handler {
  my $request = shift;  # what does shift operate on @_?
  $request-content_type('text/html');

  $request-print(END);
HTML
BODY
H1Hello There/H1
/BODY
/HTML
END

return Apache::OK;
}

2. Used Components and their Configuration:

*** using /usr/download/modperl/mod_perl-1.99_09/t/../lib/Apache/BuildConfig.pm
*** Makefile.PL options:
  MP_AP_PREFIX= /usr/httpd20
  MP_COMPAT_1X= 1
  MP_GENERATE_XS  = 1
  MP_INST_APACHE2 = 1
  MP_LIBNAME  = mod_perl
  MP_USE_DSO  = 1
  MP_USE_STATIC   = 1


__
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

Re: modperl 2.0: apache crashes when running modperl script

2003-06-03 Thread Stas Bekman

[EMAIL PROTECTED] wrote:
-8-- Start Bug Report 8--
1. Problem Description:
apache crashes when accessing this modperl script:

package Apache::hello;

use strict;

use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::Const -compile = 'OK';
sub handler {
  my $request = shift;  # what does shift operate on @_?
  $request-content_type('text/html');
  $request-print(END);
HTML
BODY
H1Hello There/H1
/BODY
/HTML
END
return Apache::OK;
}
2. Used Components and their Configuration:

*** using /usr/download/modperl/mod_perl-1.99_09/t/../lib/Apache/BuildConfig.pm
*** Makefile.PL options:
  MP_AP_PREFIX= /usr/httpd20
  MP_COMPAT_1X= 1
  MP_GENERATE_XS  = 1
  MP_INST_APACHE2 = 1
  MP_LIBNAME  = mod_perl
  MP_USE_DSO  = 1
  MP_USE_STATIC   = 1
that's only a beginning of the report. Where is the rest? Why is it so hard to 
copy-n-paste the report? OK, I'll do that for you.

 3. This is the core dump trace: (if you get a core dump):

 Apache crashes but does not dump core. I set unlimit to unlimited,
 made sure the filesystem from which 'httpd -X' is run has enough free space.
 Still no core. Could not find Bad::Segv module either in modperl or in
 CPAN and therefore could not try to dump using a script like core_dump.pl
 mentioned in 'Debugging mod_perl C Internals' document.
Yeah, I need to update the Bad::Segv part. It's called Debug::DumpCore.

 I was able to run 'httpd -X' from inside gbd and got a stack trace:

 (gdb) bt
 #0  0x402f1f47 in modperl_wbucket_write ()
from /usr/httpd20/modules/mod_perl.so
 #1  0x40638701 in mpxs_Apache__RequestRec_print ()
from 
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/Apache/RequestIO/RequestIO.so
 #2  0x406368c6 in XS_Apache__RequestRec_print ()
from 
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/Apache/RequestIO/RequestIO.so
 #3  0x403868c5 in Perl_pp_entersub ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
 #4  0x4037f059 in Perl_runops_standard ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
 #5  0x40327139 in S_call_body ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
 #6  0x40326eb6 in Perl_call_sv ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
 #7  0x402ed4e2 in modperl_callback () from /usr/httpd20/modules/mod_perl.so
 #8  0x402ed9e4 in modperl_callback_run_handlers ()
from /usr/httpd20/modules/mod_perl.so
 #9  0x402edc25 in modperl_callback_per_dir ()
from /usr/httpd20/modules/mod_perl.so
 #10 0x402e9105 in modperl_response_handler_run ()
from /usr/httpd20/modules/mod_perl.so
 #11 0x402e9325 in modperl_response_handler_cgi ()
from /usr/httpd20/modules/mod_perl.so
 #12 0x0807b67e in ap_run_handler (r=0x81a9268) at config.c:195
 #13 0x0807bb96 in ap_invoke_handler (r=0x81a9268) at config.c:401
 #14 0x0806baab in ap_process_request (r=0x81a9268) at http_request.c:288
 #15 0x08067ce9 in ap_process_http_connection (c=0x816d458) at http_core.c:293
 #16 0x08084476 in ap_run_process_connection (c=0x816d458) at connection.c:85
 #17 0x0807a234 in child_main (child_num_arg=1080249231) at prefork.c:696
 #18 0x0807a3de in make_child (s=0x80b6178, slot=0) at prefork.c:736
 #19 0x0807a437 in startup_children (number_to_start=5) at prefork.c:808
 #20 0x0807ab29 in ap_mpm_run (_pconf=0x8079b10, plog=0x80ebb50, s=0x80b6178)
 at prefork.c:1024
 #21 0x0807f842 in main (argc=2, argv=0xba74) at main.c:660
 #22 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

The problem with this trace is that it doesn't show the arguments. You need to 
build mod_perl with MP_DEBUG=1 and generate it again.

__
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

modperl 2.0: apache crashes when running modperl script

2003-06-02 Thread arunappa



I get an Internal Server Error in the browser when trying
to access the URI /hello. 

Apache and modperl version:
Sun Jun 01 18:51:42 2003] [notice] Apache/2.0.46 (Unix) mod_perl/1.99_09 Perl/v5.8.0 
mod_ssl/2.0.46 OpenSSL/0.9.6b configured -- resuming normal operations

Relvant contents of perl.conf file:
PerlRequire /home/ravi/www/apache/modperl/startup.pl
Location /hello
SetHandler perl-script
PerlHandler Apache::hello
/Location

Contents of /home/ravi/www/apache/modperl/startup.pl:
use lib /home2/apache/www/html/modperl2/book/lincoln;
1;

Script hello.pm located at /home2/apache/www/html/modperl2/book/lincoln/Apache/hello.pm

Contents of hello.pm:
package Apache::hello;

use strict;

use Apache::RequestRec ();
use Apache::RequestIO ();

sub handler {
  my $request = shift;  # what does shift operate on @_?
  $request-content_type('text/html');

  $request-print(END);   # what does the ) do in print?
HTML
BODY
H1Hello There/H1
/BODY
/HTML
END

return Apache::OK;
}

1;

Relevant httpd error_log:
[Sun Jun 01 19:04:46 2003] [notice] child pid 2861 exit signal Segmentation fault (11)

Relevant http access_log:
127.0.0.1 - - [01/Jun/2003:19:04:46 -0400] GET /hello HTTP/1.1 500 670


I am not sure if the problem is with apache or modperl.
I could not find a core file under httpd ServerRoot.

Natarajan Murugaiyan(Ravi)



__
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

Re: modperl 2.0: apache crashes when running modperl script

2003-06-02 Thread Stas Bekman

[EMAIL PROTECTED] wrote:
I get an Internal Server Error in the browser when trying
to access the URI /hello. 

Apache and modperl version:
Sun Jun 01 18:51:42 2003] [notice] Apache/2.0.46 (Unix) mod_perl/1.99_09 Perl/v5.8.0 
mod_ssl/2.0.46 OpenSSL/0.9.6b configured -- resuming normal operations
When submitting bug reports, please follow these guidelines:
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
[...]

package Apache::hello;

use strict;

use Apache::RequestRec ();
use Apache::RequestIO ();
sub handler {
  my $request = shift;  # what does shift operate on @_?
  $request-content_type('text/html');
  $request-print(END);   # what does the ) do in print?
HTML
BODY
H1Hello There/H1
/BODY
/HTML
END
return Apache::OK;
}
Where did you take this example from? you should return a constant Apache::OK, 
not a string Apache::OK. You need to import this constant before you can use 
it. Here is a skeleton:

use Apache::Const -compile = 'OK';

sub handler {
  ...
  return Apache::OK;
}
1;

Relevant httpd error_log:
[Sun Jun 01 19:04:46 2003] [notice] child pid 2861 exit signal Segmentation fault (11)
Relevant http access_log:
127.0.0.1 - - [01/Jun/2003:19:04:46 -0400] GET /hello HTTP/1.1 500 670
I am not sure if the problem is with apache or modperl.
I could not find a core file under httpd ServerRoot.
Take a look at:
http://perl.apache.org/docs/2.0/devel/debug/c.html#Getting_the_core_File_Dumped
__
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: modperl 2.0: apache crashes when running modperl script

2003-06-02 Thread Ged Haywood

Hi guys,

On Mon, 2 Jun 2003, Stas Bekman wrote:

  Sun Jun 01 18:51:42 2003] [notice] Apache/2.0.46 (Unix)
  mod_perl/1.99_09 Perl/v5.8.0 mod_ssl/2.0.46 OpenSSL/0.9.6b

http://www.openssl.org/news/secadv_20030219.txt

73,
Ged.

Re: modperl 2.0: apache crashes when running modperl script

2003-06-02 Thread arunappa



__
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455


bug.rpt
Description: bug.rpt

ModPerl::Registry and CGI::Carp

2003-05-29 Thread Adam Gent

Hi,

Is anyone having problems with modperl2 and CGI::Carp

I get this error message

[Wed May 28 18:00:57 2003] [error] 357: ModPerl::Registry: Can't locate
object method send_http_header via package Apache::RequestRec at
/usr/local/lib/perl5/5.8.0/CGI/Carp.pm line 478.

Anyone got any ideas?

Adam



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.483 / Virus Database: 279 - Release Date: 19/05/2003

Re: ModPerl::Registry and CGI::Carp

2003-05-29 Thread Perrin Harkins

On Wed, 2003-05-28 at 13:02, Adam Gent wrote:
 Is anyone having problems with modperl2 and CGI::Carp

CGI::Carp has not been ported to modperl2.  You should assume that
modules you download have not been ported unless their docs say
otherwise.

You can use the compatibility layer, or port it yourself, which is
probably not hard in this case.  See this note:
http://perl.apache.org/docs/2.0/user/porting/compat.html#C__r_E_gt_send_http_header_

- Perrin

Re: ModPerl::Registry and CGI::Carp

2003-05-29 Thread Adam Gent

Hi Perrin,

Thanks for the info.

CGI::Carp did have some code in to work with mod_perl2 but not that bit.

I have updated my copy and have sent an email to the author.

Adam

- Original Message - 
From: Perrin Harkins [EMAIL PROTECTED]
To: Adam Gent [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 6:54 PM
Subject: Re: ModPerl::Registry and CGI::Carp


 On Wed, 2003-05-28 at 13:02, Adam Gent wrote:
  Is anyone having problems with modperl2 and CGI::Carp

 CGI::Carp has not been ported to modperl2.  You should assume that
 modules you download have not been ported unless their docs say
 otherwise.

 You can use the compatibility layer, or port it yourself, which is
 probably not hard in this case.  See this note:

http://perl.apache.org/docs/2.0/user/porting/compat.html#C__r_E_gt_send_http_header_

 - Perrin



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.483 / Virus Database: 279 - Release Date: 19/05/2003

[mp2] new utils mp2bug and mp2doc and more ModPerl::MethodLookupmethods

2003-05-29 Thread Stas Bekman

I forgot to mention that 1.99_09 installs two new utils:

- mp2bug: used for success/failure reports after mod_perl was installed and 
the source is no longer available (e.g. binary distros).

- mp2doc: replaces perldoc to cope with the Apache2/ subdir (perldoc won't 
know to search under Apache2)/. So now you can do things like:

 % mp2doc Apache::Filter



Also ModPerl::MethodLookup has new useful features: print_object() and 
print_module() (there is also non-print API):

% perl -MApache2 -MModPerl::MethodLookup -e print_object Apache::RequestRec

Objects of type 'Apache::RequestRec' can invoke the following XS methods:

MethodModule
-
BINMODE   Apache::RequestIO
CLOSE Apache::RequestIO
[many more snipped]
% perl -MApache2 -MModPerl::MethodLookup -e print_module Apache::RequestRec

Module 'Apache::RequestRec' contains the following XS methods:

Method   Invoked on object type

allowed  Apache::RequestRec
allowed_methods  Apache::RequestRec
[many more snipped]
For more info see:
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html
__
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

Problems compiling modperl

2003-03-27 Thread Johnson, Fred









I havent been successful building mod_perl with apache, and
apacheSSL on a Solaris 2.8 with the latest recommended patches.

I am working on a Solaris 2.8 machine, with gcc 2.95.3, perl v5.6.1, mod_perl-1.26,
apache_1.3.22, and finally,

apache_1.3.22+ssl_1.45. 

I have been able to build this on a Solaris 2.6 machine.

Here are the errors I grabbed from the error log:



[notice] Destruction-DESTROY
called for $global_object

/tmp: Permission denied

apache_ssl.c:1617: failed assertion `0'

[notice] Destruction-DESTROY
called for $global_object

/tmp: Permission denied

apache_ssl.c:1617: failed assertion `0'

[Thu Mar 27 15:33:06 2003] [warn] [notice] child_init for
process 13816, report

any problems to
[no address given]

[Thu Mar 27 15:33:12 2003] [warn] [client 127.0.0.1] log
__ANON__ OK

Use of uninitialized value in subroutine entry at
/opt/software/mod_perl-1.26/t/

net/perl/api.pl line 222, fh1b line 1.



Any suggestions or help would be appreciated.



Fred Johnson

Systems Engineer

Storagenetworks

225 Wyman Street

Waltham, MA

(781)622-6425(o)

(781)983-1170(m)

[EMAIL PROTECTED]

Re: Problems compiling modperl

2003-03-27 Thread Ged Haywood

On Thu, 27 Mar 2003, Johnson, Fred wrote:

 I haven't been successful building mod_perl with apache, and apacheSSL
 on a Solaris 2.8 with the latest recommended patches.
 I am working on a Solaris 2.8 machine, with gcc 2.95.3, perl  v5.6.1,
 mod_perl-1.26,  apache_1.3.22, and finally,
 apache_1.3.22+ssl_1.45. 

Is there a reason for using those old versions?  I think you should be
using Apache 1.3.27 and mod_perl 1.27, and probably Perl 5.8.0.

 [notice] Destruction-DESTROY called for $global_object
 /tmp: Permission denied

It's not just a permissions problem?

Building on Solaris hasn't always been the most straightforward of
exercises.  SSL might add a little excitement.  If you trawl around in
the archives you should find people who've done it on 2.8.  I'm afraid
I don't know anything about that particular ssl version.  If that's
the problem you might try a different way of getting ssl in the mix.

73,
Ged.

ENC: [mp2.0] problems when built modperl

2003-03-26 Thread Rosane Novello











When I try to build I receive the
error above. Someone can help me?



C:\mod_perl-1.99_08perl
Makefile.PL MP_AP_PREFIX=C:\Apache Group\Apache2

Use of uninitialized value in
concatenation (.) or string at lib/ModPerl/BuildOptions.pm line 89,
DATA line 18.

Reading Makefile.PL args from @ARGV

  
MP_AP_PREFIX = C:\Apache Group\Apache2

Configuring Apache/2.0.44
mod_perl/1.99_08 Perl/v5.8.0

C:\Apache
Group\Apache2/bin/Apache.exe -l failed: Bad file descriptor at
Apache-Test/lib/Apache/TestConfig.pm line 795.







Rosane Novello

Re: ENC: [mp2.0] problems when built modperl

2003-03-26 Thread Mark James

Rosane Novello wrote:

When I try to build I receive the error above. Someone can help me?

C:\mod_perl-1.99_08perl Makefile.PL MP_AP_PREFIX=C:\Apache Group\Apache2

Use of uninitialized value in concatenation (.) or string at 
lib/ModPerl/BuildOptions.pm line 89, DATA line 18.
A comment in BuildOptions.pm states MP_AP_PREFIX may not contain spaces.

Re: ENC: [mp2.0] problems when built modperl

2003-03-26 Thread Randy Kobes

On Wed, 26 Mar 2003, Mark James wrote:

 Rosane Novello wrote:
 
  When I try to build I receive the error above. Someone can help me?
  
  C:\mod_perl-1.99_08perl Makefile.PL MP_AP_PREFIX=C:\Apache
  Group\Apache2
  
  Use of uninitialized value in concatenation (.) or string at 
  lib/ModPerl/BuildOptions.pm line 89, DATA line 18.
 
 A comment in BuildOptions.pm states MP_AP_PREFIX may not
 contain spaces.

I think having spaces in MP_AP_PREFIX is OK now in the
modperl-2.0 cvs version - you may want to try that. See
  http://perl.apache.org/download/source.html 
for links on how to obtain that.

-- 
best regards,
randy kobes

modperl apears to break my Apache DirectoryIndex

2003-03-18 Thread Merritt Krakowitzer

Hi

When i create an Apache Virtual host, It breaks the DirectoryIndex
index.html. I am using Apache/2.0.44 (Unix) mod_perl/1.99_08 Perl/v5.8.0

If I remove the following:

SetHandler perl-script
PerlHandler RT::Mason

from the virtual host config below it picks up the index.html again,
although this doesn't help cause its porked that way :) anyone have any
ideas, I just need a kick in the right direction.

VirtualHost 192.168.1.46
ServerName EISH.foo.bar
DocumentRoot /usr/local/rt3/share/html
AddDefaultCharset UTF-8
PerlModule Apache2 Apache::compat
PerlModule Apache::DBI
PerlRequire /usr/local/rt3/bin/webmux.pl
Location /
SetHandler perl-script
PerlHandler RT::Mason
/Location
/VirtualHost
(on soblin)

This E-mail contains confidential information for the addressee only. If you are not 
the intended recipient, please notify us immediately on (012) 337-5500.
You should not use, disclose, distribute or copy this communication if received in 
error. The Private Security Industry Regulatory Authority (PSIRA) does not warrant 
and/or guarantee that the integrity of this communication has been maintained nor that 
the communication is free of errors, viruses, interception,
or interference. No binding contract will result from this e-mail, until such
time as a written document is signed on behalf of PSIRA. PSIRA cannot accept any
responsibility for the completeness or accuracy of this message as it has been
transmitted over public networks.

-

RE: Trouble with sysread in modperl

2003-03-10 Thread Liu, Hui (GXS)

Title: RE: Trouble with sysread in modperl





Stas,


 We are using Oracle 9iAS (internet application server), it's bundled with the mod_perl version 1.26 (Perl 5.005). I hope this version of mod_perl is okay to use since Oracle will not support if we just upgrade the mod_perl to another version after the installation. 

 Thanks for the suggestion of read_multipart, I will ask our developers to try that out.


Regards,
Hui
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Saturday, March 08, 2003 11:14 PM
To: Liu, Hui (GXS)
Cc: [EMAIL PROTECTED]
Subject: Re: Trouble with sysread in modperl



Liu, Hui (GXS) wrote:
 Stas,
 
 Does this mean read or sysread not work properly in mod_perl and 
 we should stay away from the two functions if we write perl code to work 
 with Apache server?


I haven't said that. I doubt so. It could be a bug in your code. I've suggested:


 I suggest that you look at the implementation of the function 
 read_multipart()
 in CGI.pm, which does exactly what you want. (I see no reason why not using
 CGI.pm in first place if you can.)


Have you tried that?


Also I'm assuming that you are using mod_perl 1.x, right?


__
Stas Bekman JAm_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: Trouble with sysread in modperl

2003-03-08 Thread Stas Bekman

Liu, Hui (GXS) wrote:
Stas,

Yes we tried reading STDIN and it works:

while ($readData = STDIN) {
$buffer.= $readData;
$bufferLength   = length($buffer);
..
}
But it's not working with sysread or read, here are the results 
for read, the last line is what we expected but it's null:

   while ($bytesRead = read(STDIN, $buffer, 4096)) {
html(bytesRead=[$bytesRead] data=[$buffer]) if ($debug);
}
Here's the results from the above code :
I suggest that you look at the implementation of the function read_multipart() 
in CGI.pm, which does exactly what you want. (I see no reason why not using 
CGI.pm in first place if you can.)

And please, refrain from posting emails with huge chunks of useless 
information, in the future. Truncate to keep only the information that may 
help to understand and reproduce the problem.

__
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: Trouble with sysread in modperl

2003-03-08 Thread Liu, Hui (GXS)

Title: RE: Trouble with sysread in modperl





Stas,


 Does this mean read or sysread not work properly in mod_perl and we should stay away from the two functions if we write perl code to work with Apache server?

Regards,
Hui
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Saturday, March 08, 2003 7:09 AM
To: Liu, Hui (GXS)
Cc: [EMAIL PROTECTED]
Subject: Re: Trouble with sysread in modperl



Liu, Hui (GXS) wrote:
 Stas,
 
 Yes we tried reading STDIN and it works:
 
 while ($readData = STDIN) {
 $buffer .= $readData;
 $bufferLength = length($buffer);
 ..
 }
 
 But it's not working with sysread or read, here are the results 
 for read, the last line is what we expected but it's null:
 
 while ($bytesRead = read(STDIN, $buffer, 4096)) {
 html(bytesRead=[$bytesRead] data="" if ($debug);
 }
 
 Here's the results from the above code :


I suggest that you look at the implementation of the function read_multipart() 
in CGI.pm, which does exactly what you want. (I see no reason why not using 
CGI.pm in first place if you can.)


And please, refrain from posting emails with huge chunks of useless 
information, in the future. Truncate to keep only the information that may 
help to understand and reproduce the problem.


__
Stas Bekman JAm_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: Trouble with sysread in modperl

2003-03-08 Thread Stas Bekman

Liu, Hui (GXS) wrote:
Stas,

Does this mean read or sysread not work properly in mod_perl and 
we should stay away from the two functions if we write perl code to work 
with Apache server?
I haven't said that. I doubt so. It could be a bug in your code. I've suggested:

I suggest that you look at the implementation of the function 
read_multipart()
in CGI.pm, which does exactly what you want. (I see no reason why not using
CGI.pm in first place if you can.)
Have you tried that?

Also I'm assuming that you are using mod_perl 1.x, right?

__
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: Trouble with sysread in modperl

2003-03-05 Thread Liu, Hui (GXS)

Title: RE: Trouble with sysread in modperl





Stas,


 Yes we tried reading STDIN and it works:


 while ($readData = STDIN) {
 $buffer .= $readData;
 $bufferLength = length($buffer);
 ..
 }


 But it's not working with sysread or read, here are the results for read, the last line is what we expected but it's null:

 while ($bytesRead = read(STDIN, $buffer, 4096)) {
 html(bytesRead=[$bytesRead] data="" if ($debug);
 }


Here's the results from the above code :


bytesRead=[4096] data="">
Content-Disposition: form-data; name=sessionId


SYSTEM-admin-156534-0993
-7d33e41f304f2
Content-Disposition: form-data; name=userId


SYSTEM-admin
-7d33e41f304f2
Content-Disposition: form-data; name=bankKey


RB_AFG
-7d33e41f304f2
Content-Disposition: form-data; name=returnTo


uploadFileToEnterprise.main
-7d33e41f304f2
Content-Disposition: form-data; name=target


_top
-7d33e41f304f2
Content-Disposition: form-data; name=enterpriseConfName


send810Chrysler
-7d33e41f304f2
Content-Disposition: form-data; name=uploadFile; filename=D:\webstuff\rbc\Docs\810credit
Content-Type: text/plain


HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3549
PR|2308|27042.11
VR|1B7GL22N5YS708674|DAKR/C|2000
IR||27042.11|1769.11
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3549
PR|2308|39611.40
VR|1B7KF23Z71J222401|RAMC/Q|2001
IR||39611.40|2591.40
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3549
PR|2308|25377.19
VR|2B4GP2537YR757792|CARAVN|2000
IR||25377.19|1660.19
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3587
PR|2308|30879.13
VR|1B4GP44L7YB689425|GRDCAR|2000
IR||30879.13|2020.13
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3804
PR|2308|33067.28
VR|1B4GP44L7YB680806|GRDCAR|2000
IR||33067.28|2163.28
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3804
PR|2308|41202.49
VR|1B4HS28N4YF243809|DURNGO|2000
IR||41202.49|2695.49
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3804
PR|2308|29377.92
VR|1B7GG22N3YS698862|DAKR/C|2000
IR||29377.92|1921.92
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3804
PR|2308|42183.68
VR|1B7KF236X1J219823|RAMC/Q|2001
IR||42183.68|2759.68
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3804
PR|2308|45825.96
VR|1B7KF23651J219504|RAMC/Q|2001
IR||45825.96|2997.96
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3804
PR|2308|42716.54
VR|1B7KF23661J219494|RAMC/Q|2001
IR||42716.54|2794.54
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3804
PR|2308|42183.68
VR|1B7KF23681J219822|RAMC/Q|2001
IR||42183.68|2759.68
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3804
PR|2308|47334.66
VR|1B7MF33621J228921|RAMC/Q|2001
IR||47334.66|3096.66
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3804
PR|2308|46155.52
VR|1B7MF33791J217374|RAMC/Q|2001
IR||46155.52|3019.52
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3804
PR|2308|25799.84
VR|2B4GP2534YR748242|CARAVN|2000
IR||25799.84|1687.84
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3804
PR|2308|31910.61
VR|2C3HH56JXYH323217|INTRED|2000
IR||31910.61|2087.61
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3804
PR|2308|31910.61
VR|2C3HH56J1YH323218|INTRED|2000
IR||31910.61|2087.61
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3804
PR|2308|28307.92
VR|3B7HC13Y41G193297|RAMC/Q|2001
IR||28307.92|1851.92
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3823
PR|2308|45550.97
VR|1B7KF23611J219659|RAMC/Q|2001
IR||45550.97|2979.97
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3823
PR|2308|49393.34
VR|1B7MF33701J216680|RAM]
bytesRead=[4096] data="">
IR||49393.34|3231.34
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3823
PR|2308|28950.99
VR|3B7HC12Y01G193301|RAMC/Q|2001
IR||28950.99|1893.99
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANADA|2479
BR|BANK OF MONTREAL|000124162
DR||3917
PR|2308|38028.87
VR|1B4HS28N0YF233603|DURNGO|2000
IR||38028.87|2487.87
TR
HR|810|P||2307|071034|DEBIT
MR|CHRYSLER CANAD

Trouble with sysread in modperl

Title: Trouble with sysread in modperl





There appears to be a bug with the read and sysread functions when being used in a loop to read STDIN. We're using a loop to read from STDIN in 4k blocks, and the read or sysread appears to work great until the very last read to pick up the final partial block. Here is the code:

 $readSize = min($bytesLeft, $blockReadSize); 
 $bufferLength = length($buffer); 
 $bytesRead = sysread(STDIN, $dataRead, $readSize); 
 html(bytesRead=[$bytesRead . $bufferLength . $dataRead]) if ($debug);
 if (!(defined $bytesRead)) { 
 $bytesRead = 0; 
 } 
 $buffer .= $dataRead; 
In the last loop, the values that are returned in the debug statement are: 674 . 3268 . 
So sysread says that 674 bytes were read, however $dataRead is empty. Both read and sysread exhibit the same behavior, returning the right number of bytes to be read, but not populating the variable with the actual data. This code works fine in versions of Perl other than Apache modperl. Has anyone experienced this behavior and have any suggestions?

Re: Trouble with sysread in modperl

2003-03-04 Thread Larry Leszczynski

Hello -

 There appears to be a bug with the read and sysread functions when being
 used in a loop to read STDIN.  We're using a loop to read from STDIN in 4k
 blocks, and the read or sysread appears to work great until the very last
 read to pick up the final partial block.
[snip]

Not sure about that error, but by any chance are you trying to read POSTed
data from the request?  If so, all you need to do is:

   my $content;
   $r-read($content, $r-header_in('Content-length'));

(mod_perl cookbook recipe 3.6)


Larry Leszczynski
[EMAIL PROTECTED]

RE: Trouble with sysread in modperl

Title: RE: Trouble with sysread in modperl





Larry,


 Thanks for the suggestion. Does this mean if we have a 20MB file, this read will load the entire file into the memory?

Regards,
Hui Liu


-Original Message-
From: Larry Leszczynski [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 04, 2003 1:03 PM
To: Liu, Hui (GXS)
Cc: [EMAIL PROTECTED]
Subject: Re: Trouble with sysread in modperl



Hello -


 There appears to be a bug with the read and sysread functions when being
 used in a loop to read STDIN. We're using a loop to read from STDIN in 4k
 blocks, and the read or sysread appears to work great until the very last
 read to pick up the final partial block.
[snip]


Not sure about that error, but by any chance are you trying to read POSTed
data from the request? If so, all you need to do is:


 my $content;
 $r-read($content, $r-header_in('Content-length'));


(mod_perl cookbook recipe 3.6)



Larry Leszczynski
[EMAIL PROTECTED]

RE: Trouble with sysread in modperl

2003-03-04 Thread Larry Leszczynski

Hi Hui Liu -

  Not sure about that error, but by any chance are you trying to read
  POSTed data from the request?  If so, all you need to do is:
  
 my $content;
 $r-read($content, $r-header_in('Content-length'));
  
  (mod_perl cookbook recipe 3.6)
 
 Thanks for the suggestion. Does this mean if we have a 20MB file,
 this read will load the entire file into the memory?

Yes, at least up to the size limit defined by POST_MAX.  But if you're
trying to read uploaded files, don't do it like that.  Instead do it like
recipe 3.8 which shows how to get a filehandle to the uploaded file, e.g.
something like:

   use Apache::Request;
   sub handler {
  my $r = Apache::Request-new(shift,
   POST_MAX = 20 * 1024 * 1024,
   DISABLE_UPLOADS = 0);
  foreach my $upload ($r-upload) {
 my $fh = $upload-fh;
 ...
  }
   }


Larry Leszczynski
[EMAIL PROTECTED]

RE: Trouble with sysread in modperl

Title: RE: Trouble with sysread in modperl





Larry,


Thank you. I wonder which Mod_perl cook book you are referring to and where can we get them? I am very interested in details of recipe 3.8. This is our first time to port our perl scripts to Apache (we are using Apache:PerRun mode), and we are still learning. 

Thanks and Regards,
Hui Liu


-Original Message-
From: Larry Leszczynski [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 04, 2003 3:16 PM
To: Liu, Hui (GXS)
Cc: mod_perl list
Subject: RE: Trouble with sysread in modperl



Hi Hui Liu -


  Not sure about that error, but by any chance are you trying to read
  POSTed data from the request? If so, all you need to do is:
  
  my $content;
  $r-read($content, $r-header_in('Content-length'));
  
  (mod_perl cookbook recipe 3.6)
 
 Thanks for the suggestion. Does this mean if we have a 20MB file,
 this read will load the entire file into the memory?


Yes, at least up to the size limit defined by POST_MAX. But if you're
trying to read uploaded files, don't do it like that. Instead do it like
recipe 3.8 which shows how to get a filehandle to the uploaded file, e.g.
something like:


 use Apache::Request;
 sub handler {
 my $r = Apache::Request-new(shift,
 POST_MAX = 20 * 1024 * 1024,
 DISABLE_UPLOADS = 0);
 foreach my $upload ($r-upload) {
 my $fh = $upload-fh;
 ...
 }
 }



Larry Leszczynski
[EMAIL PROTECTED]

mod_perl books (Was: RE: Trouble with sysread in modperl)

2003-03-04 Thread Larry Leszczynski

Hi Hui Liu -

 Larry,
 
 Thank you. I wonder which Mod_perl cook book you are referring to and
 where can we get them? I am very interested in details of recipe 3.8.
 This is our first time to port our perl scripts to Apache (we are
 using Apache:PerRun mode), and we are still learning.

The best overall online resource is the mod_perl web site at:
   http://perl.apache.org/

Books related to mod_perl, including the mod_perl Developer's Cookbook,
are listed at:
   http://perl.apache.org/docs/offsite/books.html



Larry Leszczynski
[EMAIL PROTECTED]

Re: mod_perl books (Was: RE: Trouble with sysread in modperl)

2003-03-04 Thread Jordan Ward

Hi all, my name is Jordan and I've been monitoring this discussion group
learning slowly how apache and mod_perl works.
though I've rarely ever posted any questions or concerns regarding my
configurations, I found that this discussion group has provided many answers
to my multitude of questions.

I just wanted to say thanks, you've all been a great help :-)

~jordan
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: mod_perl list [EMAIL PROTECTED]
Sent: Tuesday, March 04, 2003 3:39 PM
Subject: Re: mod_perl books (Was: RE: Trouble with sysread in modperl)



 Hi Hui Liu

 You can start from
 http://perl.apache.org/docs/2.0/user/intro/start_fast.pdf instead of
 reading the very thick books. You can google to find out example codes as
 well.

 Gook Luck,

 Huili Liu






   Larry Leszczynski
   [EMAIL PROTECTED]To:   Liu, Hui (GXS)
[EMAIL PROTECTED]
   cc:   mod_perl list
[EMAIL PROTECTED]
Subject:  mod_perl books
(Was: RE: Trouble with sysread in modperl)
   03/04/2003 03:40
   PM
   Please respond to
   Larry Leszczynski







 Hi Hui Liu -

  Larry,
 
  Thank you. I wonder which Mod_perl cook book you are referring to and
  where can we get them? I am very interested in details of recipe 3.8.
  This is our first time to port our perl scripts to Apache (we are
  using Apache:PerRun mode), and we are still learning.

 The best overall online resource is the mod_perl web site at:
http://perl.apache.org/

 Books related to mod_perl, including the mod_perl Developer's Cookbook,
 are listed at:
http://perl.apache.org/docs/offsite/books.html



 Larry Leszczynski
 [EMAIL PROTECTED]

RE: mod_perl books (Was: RE: Trouble with sysread in modperl)

Title: RE: mod_perl books (Was: RE: Trouble with sysread in modperl)





Larry and Huili,


Thank you very much for the information and all your help. I just ordered a book called mod_perl Developer's Cookbook by Geoffrey Young, et al. from Amazon.com. I hope we will go from there.

Regards,
Hui Liu


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 04, 2003 3:40 PM
To: Liu, Hui (GXS)
Cc: mod_perl list
Subject: Re: mod_perl books (Was: RE: Trouble with sysread in modperl)


Hi Hui Liu


You can start from
http://perl.apache.org/docs/2.0/user/intro/start_fast.pdf instead of
reading the very thick books. You can google to find out example codes as
well.


Gook Luck,


Huili Liu
 
 Larry Leszczynski 
 [EMAIL PROTECTED] To: Liu, Hui (GXS) [EMAIL PROTECTED] 
  cc: mod_perl list [EMAIL PROTECTED] 
 Subject: mod_perl books (Was: RE: Trouble with sysread in modperl) 
 03/04/2003 03:40 
 PM 
 Please respond to 
 Larry Leszczynski 


Hi Hui Liu -


 Larry,

 Thank you. I wonder which Mod_perl cook book you are referring to and
 where can we get them? I am very interested in details of recipe 3.8.
 This is our first time to port our perl scripts to Apache (we are
 using Apache:PerRun mode), and we are still learning.


The best overall online resource is the mod_perl web site at:
 http://perl.apache.org/


Books related to mod_perl, including the mod_perl Developer's Cookbook,
are listed at:
 http://perl.apache.org/docs/offsite/books.html




Larry Leszczynski
[EMAIL PROTECTED]

Re: Trouble with sysread in modperl

2003-03-04 Thread Stas Bekman

Liu, Hui (GXS) wrote:
There appears to be a bug with the read and sysread functions when being 
used in a loop to read STDIN.  We're using a loop to read from STDIN in 
4k blocks, and the read or sysread appears to work great until the very 
last read to pick up the final partial block.  Here is the code:

   $readSize = min($bytesLeft, $blockReadSize);  
   $bufferLength  = length($buffer);  
   $bytesRead = sysread(STDIN, $dataRead, $readSize); 
   html(bytesRead=[$bytesRead . $bufferLength . $dataRead]) if ($debug);
   if (!(defined $bytesRead)) {   
   $bytesRead = 0;
   }  
   $buffer .= $dataRead;  
In the last loop, the values that are returned in the debug statement 
are:   674 . 3268 .
So sysread says that 674 bytes were read, however $dataRead is empty.  
Both read and sysread exhibit the same behavior, returning the right 
number of bytes to be read, but not populating the variable with the 
actual data.  This code works fine in versions of Perl other than Apache 
modperl.  Has anyone experienced this behavior and have any suggestions?
Could it be the buffering issue as described in the manpage?

perldoc -f sysread:

   sysread FILEHANDLE,SCALAR,LENGTH,OFFSET
   sysread FILEHANDLE,SCALAR,LENGTH
   Attempts to read LENGTH characters of data into variable SCALAR
   from the specified FILEHANDLE, using the system call read(2).
   It bypasses buffered IO, so mixing this with other kinds of
   reads, print, write, seek, tell, or eof can cause
   confusion because stdio usually buffers data.  Returns the num-
   ber of characters actually read, 0 at end of file, or undef if
   there was an error.  SCALAR will be grown or shrunk so that the
   last byte actually read is the last byte of the scalar after
   the read.
   [...]
can you try whether you get all the data, by reading via STDIN (even though 
you have no control over chunks size)



__
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

Scripts and HTML docs in the same directory (+ modperl newbie experiences)

2003-03-02 Thread Mark James

Hello All,

Took me a day, but I think I've finally been able to move my
scripts from plain cgi perl to mod_perl.  The extensive documention
on perl.apache.org was invaluable, though I have some comments below.
One question: Prior to using mod_perl I was able to have
unsuffixed scripts and .html files residing together in the
server root directory by using Apache's Files directive to
force the scripts to be executed: e.g.
Files db
ForceType application/x-httpd-cgi
/Files
I can't seem to do this with mod_perl because I now have to use
a SetHandler directive on the directory, so Apache now tries
to execute the HTML files.  I've tried forcing the scripts to
type application/x-httpd-perl, but this doesn't work.
I'd like to keep both the scripts and HTML docs in the root
directory so that URLs are as short as possible, but can I
do this with mod_perl without having to use URL re-writing?
Also having a problem with the OPEN method in Apache::RequestRec
not being found, but a reading of the list archives suggests that
an upgrade to the CVS version of mod_perl-2 will fix this.
Finally, some comments on mod_perl installation:

1. In http://perl.apache.org/docs/1.0/guide/getwet.html , use of x.x.x
   for both the Apache and mod_perl version numbers made me think that
   the version numbers had to be matched.  Maybe y.y.y should be used
   for one.  It also should be stated in this section that one has to
   use mod_perl-2.x if one is running Apache 2.y.
2. When installing mod_perl-2 I had the problem others have had with
   failed perlio tests.  Looks to be due to the test files being
   created using the real UID rather than the effective UID.
3. In the configuration section of the 2.0 docs
   (http://perl.apache.org/docs/2.0/user/intro/start_fast.html#toc_Configuration)
   it neglects to state the need to issue a directive for the mod_perl
   handler one is going to use, e.g. PerlModule ModPerl::Registry.
Thanks to all mod_perl coders!

Re: Scripts and HTML docs in the same directory (+ modperl newbieexperiences)

2003-02-27 Thread Mark James

Stas Bekman wrote:
Mark James wrote:
1. In http://perl.apache.org/docs/1.0/guide/getwet.html , use of x.x.x
   for both the Apache and mod_perl version numbers made me think that
   the version numbers had to be matched.  Maybe y.y.y should be used
   for one.  
Please get used to x.x.x meaning any. Otherwise we would need to 
remember to use z.z.z. for php plugs in and f.f.f. when openssl is 
added, etc... hope you get the idea.
When they're discussed in the same sentence, and when building one
requires linking to the installation or source directory of the other,
I think a different variable helps.
2. In the configuration section of the 2.0 docs
   
(http://perl.apache.org/docs/2.0/user/intro/start_fast.html#toc_Configuration) 

   it neglects to state the need to issue a directive for the mod_perl
   handler one is going to use, e.g. PerlModule ModPerl::Registry,
   though it is covered in the configuration docs (including the
   startup-file option).


you mean preloading the module? That's not necessarily in mp2, though 
advisable for performance reasons.

In mp2, you can say:

  PerlResponseHandler ModPerl::Registry

without:

  PerlModule ModPerl::Registry
Well I just commented out use ModPerl::Registry () in my startup
script and it still worked.  But earlier I had found that adding
PerlModule ModPerl::Registry the http.conf was the key to getting
rid of the rash of error messages I was getting on server start-up.
It must have been a manifestation of some other problem, perhaps
with mod_perl-1.99_08 (now using the CVS version to fix a missing OPEN
in Apache::RequestRec, and to avoid the failed perlio tests), or
with an older CGI.pm (found out late that CGI=2.89 was needed).

you can also use the syntactic sugar to preload modules, by simply 
stating at the beginning of your mod_perl configuration 'PerlOptions 
+Autoload'. See
http://perl.apache.org/docs/2.0/user/config/config.html#C_AutoLoad_

or using + before the handler name:

PerlResponseHandler +ModPerl::Registry
OK, so 2.0 is not like 1.0 where PerlModule acts like use()
(http://perl.apache.org/docs/1.0/guide/config.html#PerlModule_and_PerlRequire_Directives),
but is more like @INC manipulation; and these handler autoload
directives are an alternative to use-ing them in a start-up
script.
My start-up script is very long because it calls use for
just about every package in an extensive package set.
I suppose an import function could be created in a master
package of package suite that when called require-ed
all the associated packages, so that mod_perl can have the
entire suite pre-loaded prior to forking through just one
line in the start-up script.
Thank you Stas for your prompt help.

Mark

Re: Scripts and HTML docs in the same directory (+ modperl newbieexperiences)

2003-02-27 Thread Stas Bekman

Mark James wrote:
Stas Bekman wrote:

Mark James wrote:

1. In http://perl.apache.org/docs/1.0/guide/getwet.html , use of x.x.x
   for both the Apache and mod_perl version numbers made me think that
   the version numbers had to be matched.  Maybe y.y.y should be used
   for one.  
Please get used to x.x.x meaning any. Otherwise we would need to 
remember to use z.z.z. for php plugs in and f.f.f. when openssl is 
added, etc... hope you get the idea.


When they're discussed in the same sentence, and when building one
requires linking to the installation or source directory of the other,
I think a different variable helps.
since I've already changed them to be mod_perl-1.xx and apache_1.3.xx there 
shouldn't be a confusion anymore.

2. In the configuration section of the 2.0 docs
   
(http://perl.apache.org/docs/2.0/user/intro/start_fast.html#toc_Configuration) 

   it neglects to state the need to issue a directive for the mod_perl
   handler one is going to use, e.g. PerlModule ModPerl::Registry,
   though it is covered in the configuration docs (including the
   startup-file option).


you mean preloading the module? That's not necessarily in mp2, though 
advisable for performance reasons.

In mp2, you can say:

  PerlResponseHandler ModPerl::Registry

without:

  PerlModule ModPerl::Registry


Well I just commented out use ModPerl::Registry () in my startup
script and it still worked.  But earlier I had found that adding
PerlModule ModPerl::Registry the http.conf was the key to getting
rid of the rash of error messages I was getting on server start-up.
It must have been a manifestation of some other problem, perhaps
with mod_perl-1.99_08 (now using the CVS version to fix a missing OPEN
in Apache::RequestRec, and to avoid the failed perlio tests), or
with an older CGI.pm (found out late that CGI=2.89 was needed).
Bugs get fixed ;)

you can also use the syntactic sugar to preload modules, by simply 
stating at the beginning of your mod_perl configuration 'PerlOptions 
+Autoload'. See
http://perl.apache.org/docs/2.0/user/config/config.html#C_AutoLoad_

or using + before the handler name:

PerlResponseHandler +ModPerl::Registry


OK, so 2.0 is not like 1.0 where PerlModule acts like use()
(http://perl.apache.org/docs/1.0/guide/config.html#PerlModule_and_PerlRequire_Directives), 

but is more like @INC manipulation; and these handler autoload
directives are an alternative to use-ing them in a start-up
script.
No, it works exactly the same. It's just that in 2.0 you don't have to preload 
the modules. An attempt to load them will happen when they will be used for 
the first time.

My start-up script is very long because it calls use for
just about every package in an extensive package set.
I suppose an import function could be created in a master
package of package suite that when called require-ed
all the associated packages, so that mod_perl can have the
entire suite pre-loaded prior to forking through just one
line in the start-up script.
You can certainly do that. Or you can even preload *all* available mp2 packages :)
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#preload_all_modules__
Thank you Stas for your prompt help.
;)



__
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

perl 5.8.0/modperl 1.99/apache2/HPUX 11.00 config problem

2003-02-26 Thread Nathan Sweaney

OK, I've installed perl  apache 2 fine.  Then I try to configure mod_perl 1.99_08, 
using the command:
 # perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2
 it seems to work fine except for this warning:

 Reading Makefile.PL args from @ARGV
MP_AP_PREFIX = /usr/local/apache2
 * WARNING *

   mod_perl is unlikely to link with your libperl, suggestions:
 *) Rebuild Perl with Configure -Accflags=+Z ...


 * WARNING *
 Configuring Apache/2.0.43 mod_perl/1.99_08 Perl/v5.8.0

But it doesn't stop, it just keeps going  acts all happy.
Then when I run make i get:

 /usr/bin/ld: DP relative code in file 
/usr/local/lib/perl5/5.8.0/PA-RISC1.1/auto/DynaLoader/DynaLoader.a (DynaLoader.o) - 
shared library must be position
 independent.  Use +z or +Z to recompile.
 *** Error exit code 1

 Stop.
 *** Error exit code 1

 Stop.
 #

I've tried recompiling perl numerous times, but i'm basically a total newb.  I'm a 
college student with no experience on HPUX  very little unix experience to begin 
with, but somehow I ended up responsible for this, so any help would be greatly 
appreciated. 

 thanks.
Nathan Sweaney

Re: perl 5.8.0/modperl 1.99/apache2/HPUX 11.00 config problem

2003-02-26 Thread Stas Bekman

Nathan Sweaney wrote:
OK, I've installed perl  apache 2 fine.  Then I try to configure mod_perl 1.99_08, 
using the command:
 # perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2
 it seems to work fine except for this warning:
 Reading Makefile.PL args from @ARGV
MP_AP_PREFIX = /usr/local/apache2
 * WARNING *
   mod_perl is unlikely to link with your libperl, suggestions:
 *) Rebuild Perl with Configure -Accflags=+Z ...
I suppose, it's because in some cases it works so Doug made it a warning, 
rather than an assertion. Or may be so mod_perl build can be tested without 
fixing perl ;)

 * WARNING *
 Configuring Apache/2.0.43 mod_perl/1.99_08 Perl/v5.8.0
But it doesn't stop, it just keeps going  acts all happy.
Then when I run make i get:
 /usr/bin/ld: DP relative code in file 
/usr/local/lib/perl5/5.8.0/PA-RISC1.1/auto/DynaLoader/DynaLoader.a (DynaLoader.o) - 
shared library must be position
 independent.  Use +z or +Z to recompile.
 *** Error exit code 1
 Stop.
 *** Error exit code 1
 Stop.
 #
I've tried recompiling perl numerous times, but i'm basically a total newb.  I'm a college student with no experience on HPUX  very little unix experience to begin with, but somehow I ended up responsible for this, so any help would be greatly appreciated. 
well, since your problem now is compiling perl with -Accflags=+Z enabled, it's 
no longer a mod_perl question and should be taken elsewhere.

However, this may help:
http://perl.apache.org/docs/2.0/user/install/install.html#Configuring_and_Installing_Prerequisites
just add the -Accflags=+Z, to the ./Configure command as described in that 
document.

If you still have problems you should try one of the resources listed here: 
http://perl.apache.org/docs/offsite/other.html#Perl

__
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

Scripts and HTML docs in the same directory (+ modperl newbie experiences)

2003-02-26 Thread Mark James

Hello All,

Took me a day, but I think I've finally been able to move my
scripts from plain cgi perl to mod_perl2.  The extensive documention
on perl.apache.org was invaluable, though I have some comments below.
One question: Prior to using mod_perl I was able to have
unsuffixed scripts and .html files residing together in the
server root directory by using Apache's Files directive to
force the scripts to be executed: e.g.
Files db
ForceType application/x-httpd-cgi
/Files
I can't seem to do this with mod_perl because I now have to use
a SetHandler directive on the directory, so Apache now executes
the HTML files.  I've tried forcing the scripts to type
application/x-httpd-perl, but this doesn't work.
I'd like to keep both the scripts and HTML docs in the root
directory so that URLs are as short as possible, but can I
do this with mod_perl without having to use URL re-writing?
Finally, some comments on mod_perl installation:

1. In http://perl.apache.org/docs/1.0/guide/getwet.html , use of x.x.x
   for both the Apache and mod_perl version numbers made me think that
   the version numbers had to be matched.  Maybe y.y.y should be used
   for one.  It also should be stated in this section that one has to
   use mod_perl-2.x if one is running Apache 2.y.
2. In the configuration section of the 2.0 docs
   (http://perl.apache.org/docs/2.0/user/intro/start_fast.html#toc_Configuration)
   it neglects to state the need to issue a directive for the mod_perl
   handler one is going to use, e.g. PerlModule ModPerl::Registry,
   though it is covered in the configuration docs (including the
   startup-file option).
Thanks to all mod_perl coders!

Re: Scripts and HTML docs in the same directory (+ modperl newbieexperiences)

2003-02-26 Thread Perrin Harkins

On Wed, 2003-02-26 at 23:16, Mark James wrote:
 One question: Prior to using mod_perl I was able to have
 unsuffixed scripts and .html files residing together in the
 server root directory by using Apache's Files directive to
 force the scripts to be executed: e.g.
 
  Files db
  ForceType application/x-httpd-cgi
  /Files
 
 I can't seem to do this with mod_perl because I now have to use
 a SetHandler directive on the directory

You should be able to do the SetHandler inside a Files directive just
like you did with ForceType.  Have you tried that?

- Perrin

Re: Scripts and HTML docs in the same directory (+ modperl newbieexperiences)

2003-02-26 Thread Stas Bekman

Mark James wrote:
Hello All,

Took me a day, but I think I've finally been able to move my
scripts from plain cgi perl to mod_perl2.  The extensive documention
on perl.apache.org was invaluable, though I have some comments below.
One question: Prior to using mod_perl I was able to have
unsuffixed scripts and .html files residing together in the
server root directory by using Apache's Files directive to
force the scripts to be executed: e.g.
Files db
ForceType application/x-httpd-cgi
/Files
I can't seem to do this with mod_perl because I now have to use
a SetHandler directive on the directory, so Apache now executes
the HTML files.  I've tried forcing the scripts to type
application/x-httpd-perl, but this doesn't work.
I'd like to keep both the scripts and HTML docs in the root
directory so that URLs are as short as possible, but can I
do this with mod_perl without having to use URL re-writing?
Set the normal behavior per dir/location and then override for specific files

  Location /perl
 SetHandler perl-script
 ...
  /Location
  Files *.html
SetHandler default
  /Files
if I remember correctly you can even nest that Files container inside the 
Location container.

Finally, some comments on mod_perl installation:

1. In http://perl.apache.org/docs/1.0/guide/getwet.html , use of x.x.x
   for both the Apache and mod_perl version numbers made me think that
   the version numbers had to be matched.  Maybe y.y.y should be used
   for one.  
Please get used to x.x.x meaning any. Otherwise we would need to remember to 
use z.z.z. for php plugs in and f.f.f. when openssl is added, etc... hope you 
get the idea.

It also should be stated in this section that one has to
   use mod_perl-2.x if one is running Apache 2.y.
yup, thank you, will fix that shortly.

2. In the configuration section of the 2.0 docs
   
(http://perl.apache.org/docs/2.0/user/intro/start_fast.html#toc_Configuration) 

   it neglects to state the need to issue a directive for the mod_perl
   handler one is going to use, e.g. PerlModule ModPerl::Registry,
   though it is covered in the configuration docs (including the
   startup-file option).
you mean preloading the module? That's not necessarily in mp2, though 
advisable for performance reasons.

In mp2, you can say:

  PerlResponseHandler ModPerl::Registry

without:

  PerlModule ModPerl::Registry

you can also use the syntactic sugar to preload modules, by simply stating at 
the beginning of your mod_perl configuration 'PerlOptions +Autoload'. See
http://perl.apache.org/docs/2.0/user/config/config.html#C_AutoLoad_

or using + before the handler name:

PerlResponseHandler +ModPerl::Registry

Thanks to all mod_perl coders!
Thanks for the comments.

__
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: Scripts and HTML docs in the same directory (+ modperl newbieexperiences)

2003-02-26 Thread Mark James

Perrin Harkins wrote:
You should be able to do the SetHandler inside a Files directive just
like you did with ForceType.  Have you tried that?
Thanks Perrin, that worked.  I didn't think SetHandler directives
were allowed in Files sections, because it's not listed in the SetHandler
docs (http://httpd.apache.org/docs-2.0/mod/core.html#sethandler), unlike
ForceType docs (http://httpd.apache.org/docs-2.0/mod/core.html#forcetype)
Stas Bekman wrote:
 Set the normal behavior per dir/location and then override for specific
 files
Stas' solution would therefore work as well.

Mark

mp2: a new helper module: ModPerl::MethodLookup

2003-02-23 Thread Stas Bekman

I've just committed a new module, called ModPerl::MethodLookup to figure out 
which modules to load for wanted functionality, or to simply preload all 
mod_perl modules. For more info see:
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html

__
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: HELP - Problem installing modperl

2003-02-23 Thread Stas Bekman

Pablo Jejcic wrote:
Here is my 'perl -V'.

Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
[...]
  Compiler:
cc='cc', ccflags ='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
[...]
cccdlflags='-KPIC', lddlflags='-G'
Still, either you aren't using the same compiler as you've used to build perl 
or the build has a wrong Config.pm.

I've read a few threads on this issue via google and they all say the same 
thing: You must be using the native Solaris cc to build mod_perl (which 
doesn't support -KPIC). Your perl must have been built with gcc.

Try to rebuild mod_perl, with

CC=gcc perl Makefile ...

__
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: HELP - Problem installing modperl

2003-02-21 Thread Pablo Jejcic

 Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]] 
Sent: 20 February 2003 23:09
To: Pablo Jejcic
Cc: [EMAIL PROTECTED]
Subject: Re: HELP - Problem installing modperl


Pablo Jejcic wrote:
  I rebuild PERL and when I use perl -V I can see -KPIC but when I try
  to make mod_perl I receive the same error
  
  Any other thoughts???

How is it possible that the same compiler accepts an option for building one

program, but not the other? Can you please post your 'perl -V'?

__
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

cvs commit: modperl-2.0/lib/ModPerl BuildOptions.pm

2003-02-20 Thread randyk

randyk  2003/02/19 21:19:14

  Modified:lib/ModPerl BuildOptions.pm
  Log:
  Reviewed by: stas
  
  Revision  ChangesPath
  1.17  +7 -0  modperl-2.0/lib/ModPerl/BuildOptions.pm
  
  Index: BuildOptions.pm
  ===
  RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildOptions.pm,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- BuildOptions.pm   21 May 2002 16:48:29 -  1.16
  +++ BuildOptions.pm   20 Feb 2003 05:19:14 -  1.17
  @@ -3,6 +3,7 @@
   use strict;
   use warnings;
   
  +use Apache::Build ();
   my $param_qr = qr([\s=]+);
   
   use constant VERBOSE = 1;
  @@ -66,6 +67,12 @@
   if($key eq 'MP_APXS') {
   $val = File::Spec-canonpath(File::Spec-rel2abs($val));
   }
  +
  + # MP_AP_PREFIX may not contain spaces
  + if ($key eq 'MP_AP_PREFIX'  Apache::Build::WIN32()) {
  +require Win32;
  + $val = Win32::GetShortPathName($val);
  + }
   
   if ($self-{$key}) {
   $self-{$key} .= ' ';

RE: HELP - Problem installing modperl

2003-02-20 Thread Pablo Jejcic

 I rebuild PERL and when I use perl -V I can see -KPIC but when I try 
 to make mod_perl I receive the same error
 
 Any other thoughts???
 
 Thanks in advance and Thank you very much for your time.-
 
 Kind Regards.
   _
 
 Pablo Jejcic
 Smartweb Senior system Administrator
 School of Computing - Robert Gordon University 
 [EMAIL PROTECTED] T:44-(0)1224-262797
 F:44-(0)1224-262790 
   _  
 
 
 ``The nice thing about standards is that there are so many to choose 
 from. And if you really don't like all the standards you just have to 
 wait another year until the one arises you are looking for.'' A. 
 Tanenbaum, ``Introduction to Computer Networks'
 
   _
 
 
 
 -Original Message-
 From: Stas Bekman [mailto:[EMAIL PROTECTED]]
 Sent: 18 February 2003 23:02
 To: Pablo Jejcic
 Cc: [EMAIL PROTECTED]
 Subject: Re: HELP - Problem installing modperl
 
 
 Pablo Jejcic wrote:
 
Hello guys,
I have just installed PERL/Apache and mod_perl, but this last 
one gave me an error when I try to compile. Could anyone help me?
 
Thi is the error:
 
bash-2.05# make  make test
cd src/modules/perl  make -f Makefile.modperl
make[1]: Entering directory 
`/projects/IRIG/mod_perl-1.99_08/src/modules/perl'
cc -I/projects/IRIG/mod_perl-1.99_08/src/modules/perl
-I/projects/IRIG/mod_perl-1.99_08/xs 
-I/projects/IRIG/apache2/prefork/include 
-I/usr/perl5/5.6.1/lib/sun4-solaris-64int/CORE -DMOD_PERL -xO3 -xdepend 
-KPIC \
-c mod_perl.c  mv mod_perl.o mod_perl.lo
cc: unrecognized option `-KPIC'
 
 
 mod_perl reuses the compiler flags perl was built with. It picks them 
 up from Config.pm. Do you see -KPIC in the output of 'perl -V'? You 
 must use exactly
 
 the same compiler that you've built your perl with and it should work.
 
 
cc: language depend not recognized
cc: mod_perl.c: linker input file unused because linking not done
mv: cannot access mod_perl.o
make[1]: *** [mod_perl.lo] Error 2
make[1]: Leaving directory 
`/projects/IRIG/mod_perl-1.99_08/src/modules/perl'
make: *** [modperl_lib] Error 2
bash-2.05# c
bash: c: command not found
bash-2.05# cc
cc: no input files
And I'm running:
 
Solaris 9
PERL 5.6.1
Apache 2.0.4
mod_perl 1.99_08
 
Thanks in advance!!
 
Pablo.-
 
Kind Regards.
--
--
Pablo Jejcic
Smartweb Senior system Administrator
School of Computing - Robert Gordon University 
[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]
*T*:44-(0)1224-262797
*F*:44-(0)1224-262790


``The nice thing about standards is that there are so many to choose 
from. And if you really don't like all the standards you just have to 
wait another year until the one arises you are looking for.'' A. 
Tanenbaum, ``Introduction to Computer Networks'

--
--

 
 
 
 


-- 


__
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: HELP - Problem installing modperl

2003-02-20 Thread Stas Bekman

Pablo Jejcic wrote:

 I rebuild PERL and when I use perl -V I can see -KPIC but when I try 
 to make mod_perl I receive the same error
 
 Any other thoughts???

How is it possible that the same compiler accepts an option for building one 
program, but not the other? Can you please post your 'perl -V'?

__
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

cvs commit: modperl Makefile.PL

2003-02-20 Thread randyk

randyk  2003/02/20 08:34:35

  Modified:.Makefile.PL
  Log:
  Reviewed by:  stas
  
  Enable PERL_SECTIONS for Win32
  
  Revision  ChangesPath
  1.207 +2 -1  modperl/Makefile.PL
  
  Index: Makefile.PL
  ===
  RCS file: /home/cvs/modperl/Makefile.PL,v
  retrieving revision 1.206
  retrieving revision 1.207
  diff -u -r1.206 -r1.207
  --- Makefile.PL   20 Feb 2003 16:28:35 -  1.206
  +++ Makefile.PL   20 Feb 2003 16:34:35 -  1.207
  @@ -792,7 +792,8 @@
(need 1.2.0 or higher);
   }
   
  -$PERL_SECTIONS = $PERL_SSI = 0 if $Is_Win32;
  +#$PERL_SECTIONS = $PERL_SSI = 0 if $Is_Win32;
  +$PERL_SSI = 0 if $Is_Win32;
   unless ($Is_Win32) {
 for (qw(PERL_SECTIONS PERL_SSI), keys %experimental) {
$k = $_;

cvs commit: modperl Makefile.PL

2003-02-20 Thread randyk

randyk  2003/02/20 08:42:46

  Modified:.Makefile.PL
  Log:
  Reviewed by:  stas
  
  Use Perl's touch(), in case a system touch() isn't available.
  
  Revision  ChangesPath
  1.208 +5 -1  modperl/Makefile.PL
  
  Index: Makefile.PL
  ===
  RCS file: /home/cvs/modperl/Makefile.PL,v
  retrieving revision 1.207
  retrieving revision 1.208
  diff -u -r1.207 -r1.208
  --- Makefile.PL   20 Feb 2003 16:34:35 -  1.207
  +++ Makefile.PL   20 Feb 2003 16:42:46 -  1.208
  @@ -1602,7 +1602,11 @@
my $to = '$(INST_ARCHLIB)/' . auto/Apache/include/$_;
unless ($self-{PM}-{$from}) {
$self-{PM}-{$from} = $to;
  - system $Config{touch} $from;
  +#system $Config{touch} $from;
  + my @args = ($Config{perlpath}, '-MExtUtils::Command', 
  + '-e', 'touch', $from);
  + system(@args) == 0
  + or die system @args failed: $?;
}
   }

Re: cvs commit: modperl Makefile.PL

2003-02-20 Thread Stas Bekman

[EMAIL PROTECTED] wrote:
randyk  2003/02/20 08:42:46

  Modified:.Makefile.PL
  Log:
  Reviewed by:	stas
  
  Use Perl's touch(), in case a system touch() isn't available.
  
  Revision  ChangesPath
  1.208 +5 -1  modperl/Makefile.PL
  
  Index: Makefile.PL
  ===
  RCS file: /home/cvs/modperl/Makefile.PL,v
  retrieving revision 1.207
  retrieving revision 1.208
  diff -u -r1.207 -r1.208
  --- Makefile.PL	20 Feb 2003 16:34:35 -	1.207
  +++ Makefile.PL	20 Feb 2003 16:42:46 -	1.208
   -1602,7 +1602,11 
   	my $to = '$(INST_ARCHLIB)/' . auto/Apache/include/$_;
   	unless ($self-{PM}-{$from}) {
   	$self-{PM}-{$from} = $to;
  -	system $Config{touch} $from;
  +#	system $Config{touch} $from;
  +	my args = ($Config{perlpath}, '-MExtUtils::Command', 
  +		'-e', 'touch', $from);
  +	system(args) == 0
  +	or die system args failed: $?;
   	}
   }
since we use cvs, we don't commented out snippets of the older code that was 
replaced with the new one. If in the future we realize the the recent change 
broke something we can always revert to the previous version. So please remove 
this commented out line and the same in your other commit on PERL_SECTIONS. 
Thanks.

BTW, in case you were wondering. the style guide doesn't apply to the modperl 
(1.0) rep, since it's all a mess. We try to keep it clean for 2.0 from the 
very beginning.

__
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

cvs commit: modperl-2.0/t/response/TestCompat conn_authen.pm

2003-02-19 Thread geoff

geoff   2003/02/19 06:14:36

  Modified:.Changes
   lib/Apache compat.pm
   t/response/TestCompat conn_authen.pm
  Log:
  fixes to Apache::compat. make $r-connection-auth_type interface
  with r-ap_auth_type. make both $r-connection-auth_type and
  $r-connection-user writable
  Submitted by: geoff
  Reviewed by:  stas
  
  Revision  ChangesPath
  1.129 +4 -0  modperl-2.0/Changes
  
  Index: Changes
  ===
  RCS file: /home/cvs/modperl-2.0/Changes,v
  retrieving revision 1.128
  retrieving revision 1.129
  diff -u -r1.128 -r1.129
  --- Changes   19 Feb 2003 14:12:01 -  1.128
  +++ Changes   19 Feb 2003 14:14:35 -  1.129
  @@ -10,6 +10,10 @@
   
   =item 1.99_09-dev
   
  +fixes to Apache::compat. make $r-connection-auth_type interface
  +with r-ap_auth_type. make both $r-connection-auth_type and
  +$r-connection-user writable. [Geoffrey Young]
  +
   Open up r-ap_auth_type, making it possible to write custom
   authen handlers that don't rely on Basic authentication or
   it's associated ap_* functions.
  
  
  
  1.80  +2 -2  modperl-2.0/lib/Apache/compat.pm
  
  Index: compat.pm
  ===
  RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
  retrieving revision 1.79
  retrieving revision 1.80
  diff -u -r1.79 -r1.80
  --- compat.pm 17 Feb 2003 09:47:31 -  1.79
  +++ compat.pm 19 Feb 2003 14:14:36 -  1.80
  @@ -538,8 +538,8 @@
   
   # auth_type and user records don't exist in 2.0 conn_rec struct
   # 'PerlOptions +GlobalRequest' is required
  -sub auth_type { Apache-request-auth_type }
  -sub user  { Apache-request-user  }
  +sub auth_type { shift; Apache-request-ap_auth_type(@_) }
  +sub user  { shift; Apache-request-user(@_)  }
   
   1;
   __END__
  
  
  
  1.2   +33 -5 modperl-2.0/t/response/TestCompat/conn_authen.pm
  
  Index: conn_authen.pm
  ===
  RCS file: /home/cvs/modperl-2.0/t/response/TestCompat/conn_authen.pm,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- conn_authen.pm12 Feb 2003 23:42:23 -  1.1
  +++ conn_authen.pm19 Feb 2003 14:14:36 -  1.2
  @@ -1,6 +1,6 @@
   package TestCompat::conn_authen;
   
  -# simply check that we can retrieve:
  +# compat checks for
   #   $r-connection-auth_type
   #   $r-connection-user
   # both records don't exist in 2.0 conn_rec and therefore require
  @@ -16,19 +16,47 @@
   use Apache::Constants qw(OK REMOTE_HOST);
   
   sub handler {
  +
   my $r = shift;
   
  +my $req_auth_type = $r-connection-auth_type || '';
  +
  +die request auth_type is '$req_auth_type', should be empty
  +if $req_auth_type;
  +
  +# get_basic_auth_pw populates $r-user and $r-ap_auth_type
   my($rc, $sent_pw) = $r-get_basic_auth_pw;
   
   return $rc if $rc != Apache::OK;
   
  -my $auth_type = $r-connection-auth_type || '';
  -die auth_type is '$auth_type', should be 'Basic' 
  -unless $auth_type eq 'Basic';
  +$req_auth_type = $r-connection-auth_type || '';
  +
  +die request auth_type is '$req_auth_type', should be 'Basic'
  +unless $req_auth_type eq 'Basic';
  +
  +my $config_auth_type = $r-auth_type || '';
  +
  +die httpd.conf auth_type is '$config_auth_type', should be 'Basic'
  +unless $config_auth_type eq 'Basic';
   
   my $user = $r-connection-user || '';
  -die user is '$user', while expecting 'dougm'
  +
  +die user is '$user', should be 'dougm'
   unless $user eq 'dougm';
  +
  +# make sure we can set both
  +$r-connection-auth_type('sailboat');
  +$r-connection-user('geoff');
  +
  +$user = $r-connection-user || '';
  +
  +die user is '$user', should be 'geoff'
  +unless $user eq 'geoff';
  +
  +$req_auth_type = $r-connection-auth_type || '';
  +
  +die request auth_type is '$req_auth_type', should be 'sailboat'
  +unless $req_auth_type eq 'sailboat';
   
   OK;
   }

cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm

stas2003/02/19 15:55:23

  Modified:.Changes
   lib/Apache compat.pm
   t/response/TestCompat apache.pm
   xs/Apache/Response Apache__Response.h
   xs/maps  modperl_functions.map
   xs/tables/current/ModPerl FunctionTable.pm
  Log:
  move $r-send_http_header implementation to Apache::compat.  This
  allows the 1.0 code to run unmodified if $r-send_http_header is
  called before the response change. we already handle the check whether
  content_type was set, when deciding whether the headers are to be
  parsed inside modperl_wbucket_pass().
  
  Revision  ChangesPath
  1.130 +6 -0  modperl-2.0/Changes
  
  Index: Changes
  ===
  RCS file: /home/cvs/modperl-2.0/Changes,v
  retrieving revision 1.129
  retrieving revision 1.130
  diff -u -r1.129 -r1.130
  --- Changes   19 Feb 2003 14:14:35 -  1.129
  +++ Changes   19 Feb 2003 23:55:22 -  1.130
  @@ -10,6 +10,12 @@
   
   =item 1.99_09-dev
   
  +move $r-send_http_header implementation to Apache::compat.  This
  +allows the 1.0 code to run unmodified if $r-send_http_header is
  +called before the response change. we already handle the check whether
  +content_type was set, when deciding whether the headers are to be
  +parsed inside modperl_wbucket_pass(). [Stas]
  +
   fixes to Apache::compat. make $r-connection-auth_type interface
   with r-ap_auth_type. make both $r-connection-auth_type and
   $r-connection-user writable. [Geoffrey Young]
  
  
  
  1.81  +5 -0  modperl-2.0/lib/Apache/compat.pm
  
  Index: compat.pm
  ===
  RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
  retrieving revision 1.80
  retrieving revision 1.81
  diff -u -r1.80 -r1.81
  --- compat.pm 19 Feb 2003 14:14:36 -  1.80
  +++ compat.pm 19 Feb 2003 23:55:23 -  1.81
  @@ -154,6 +154,11 @@
   return Apache::current_callback();
   }
   
  +sub send_http_header {
  +my ($r, $type) = @_;
  +$r-content_type($type) if defined $type;
  +}
  +
   #to support $r-server_root_relative
   *server_root_relative = \Apache::server_root_relative;
   
  
  
  
  1.5   +3 -0  modperl-2.0/t/response/TestCompat/apache.pm
  
  Index: apache.pm
  ===
  RCS file: /home/cvs/modperl-2.0/t/response/TestCompat/apache.pm,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- apache.pm 17 Feb 2003 09:03:17 -  1.4
  +++ apache.pm 19 Feb 2003 23:55:23 -  1.5
  @@ -55,3 +55,6 @@
   
   1;
   
  +__END__
  +# so we can test whether send_httpd_header() works fine
  +PerlOptions +ParseHeaders
  
  
  
  1.9   +0 -22 modperl-2.0/xs/Apache/Response/Apache__Response.h
  
  Index: Apache__Response.h
  ===
  RCS file: /home/cvs/modperl-2.0/xs/Apache/Response/Apache__Response.h,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- Apache__Response.h17 Jan 2003 02:26:31 -  1.8
  +++ Apache__Response.h19 Feb 2003 23:55:23 -  1.9
  @@ -13,28 +13,6 @@
   rcfg-wbucket-header_parse = 0; \
   }
   
  -/* XXX: should only be part of Apache::compat */
  -static MP_INLINE void
  -mpxs_Apache__RequestRec_send_http_header(pTHX_ request_rec *r,
  - const char *type)
  -{
  -MP_dRCFG;
  -
  -if (type) {
  -ap_set_content_type(r, apr_pstrdup(r-pool, type));
  -}
  -
  -if (rcfg-wbucket) {
  -/* turn off PerlOptions +ParseHeaders */
  -rcfg-wbucket-header_parse = 0; 
  -}
  -else {
  -/* the response is not initialized yet */
  -Perl_croak(aTHX_ send_http_header() can't be called before 
  -   the response phase);
  -}
  -}
  -
   static MP_INLINE void
   mpxs_Apache__RequestRec_set_last_modified(request_rec *r, apr_time_t mtime)
   {
  
  
  
  1.54  +0 -1  modperl-2.0/xs/maps/modperl_functions.map
  
  Index: modperl_functions.map
  ===
  RCS file: /home/cvs/modperl-2.0/xs/maps/modperl_functions.map,v
  retrieving revision 1.53
  retrieving revision 1.54
  diff -u -r1.53 -r1.54
  --- modperl_functions.map 17 Feb 2003 09:03:17 -  1.53
  +++ modperl_functions.map 19 Feb 2003 23:55:23 -  1.54
  @@ -56,7 +56,6 @@
   
   MODULE=Apache::Response   PACKAGE=Apache::RequestRec
   DEFINE_send_cgi_header | | request_rec *:r, SV *:buffer
  - mpxs_Apache__RequestRec_send_http_header | | r, type=NULL
mpxs_Apache__RequestRec_set_last_modified | | r, mtime=0
   
   
  
  
  
  1.105 +0 -18 modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm
  
  Index: FunctionTable.pm

cvs commit: modperl-2.0 STATUS

stas2003/02/19 16:41:51

  Modified:.STATUS
  Log:
  need to resolve the issue with END blocks
  
  Revision  ChangesPath
  1.34  +5 -1  modperl-2.0/STATUS
  
  Index: STATUS
  ===
  RCS file: /home/cvs/modperl-2.0/STATUS,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- STATUS15 Jan 2003 05:22:53 -  1.33
  +++ STATUS20 Feb 2003 00:41:51 -  1.34
  @@ -50,6 +50,10 @@
   Needs Patch or Further Investigation:
   -
   
  +* child processes never run END blocks. a good example is
  +  Apache::TestUtil, which doesn't cleanup files and dirs it has
  +  created, because the END block is not run.
  +
   * Currently modperl_filter_add_{connection|request} check the filter
 handler function attrs before accepting the filter. If the module
 wasn't preloaded the check fails and filter handler is skipped. We

cvs commit: modperl-2.0 Changes

stas2003/02/19 17:28:25

  Modified:t/response/TestAPI uri.pm
   xs/APR/URI APR__URI.h
   .Changes
  Log:
  fix a bug for apr  0.9.3, where it segfaults in apr_uri_unparse, if
  hostname is set, but not the scheme.
  
  Revision  ChangesPath
  1.9   +13 -1 modperl-2.0/t/response/TestAPI/uri.pm
  
  Index: uri.pm
  ===
  RCS file: /home/cvs/modperl-2.0/t/response/TestAPI/uri.pm,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- uri.pm14 May 2002 01:32:50 -  1.8
  +++ uri.pm20 Feb 2003 01:28:24 -  1.9
  @@ -4,6 +4,7 @@
   use warnings FATAL = 'all';
   
   use Apache::Test;
  +use Apache::TestUtil;
   
   use APR::URI ();
   use Apache::URI ();
  @@ -17,7 +18,7 @@
   sub handler {
   my $r = shift;
   
  -plan $r, tests = 14;
  +plan $r, tests = 15;
   
   $r-args('query');
   
  @@ -49,6 +50,17 @@
   $parsed-path($path);
   
   ok $parsed-path eq $path;
  +
  +{
  +# test the segfault in apr  0.9.3 (fixed on mod_perl side)
  +# passing only the /path
  +my $parsed = APR::URI-parse($r-pool, $r-uri);
  +# set hostname, but not the scheme
  +$parsed-hostname($r-get_server_name);
  +$parsed-port($r-get_server_port);
  +#$parsed-scheme('http'); 
  +ok t_cmp($r-construct_url, $parsed-unparse);
  +}
   
   my $newr = Apache::RequestRec-new($r-connection, $r-pool);
   my $url_string = $path?query;
  
  
  
  1.5   +9 -0  modperl-2.0/xs/APR/URI/APR__URI.h
  
  Index: APR__URI.h
  ===
  RCS file: /home/cvs/modperl-2.0/xs/APR/URI/APR__URI.h,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- APR__URI.h14 May 2002 01:32:50 -  1.4
  +++ APR__URI.h20 Feb 2003 01:28:24 -  1.5
  @@ -3,6 +3,15 @@
  apr_uri_t *uptr,
  unsigned flags)
   {
  +
  +/* XXX: check that my patch was actually applied in apr v9.3 */
  +#if APR_MINOR_VERSION == 9  APR_PATCH_VERSION  3
  +/* apr  0.9.3 segfaults if hostname is set, but scheme is not */
  +if (uptr-hostname  !uptr-scheme) {
  +uptr-scheme = http;
  +}
  +#endif
  +
   return apr_uri_unparse(((modperl_uri_t *)uptr)-pool,
  uptr, flags);
   }
  
  
  
  1.131 +3 -0  modperl-2.0/Changes
  
  Index: Changes
  ===
  RCS file: /home/cvs/modperl-2.0/Changes,v
  retrieving revision 1.130
  retrieving revision 1.131
  diff -u -r1.130 -r1.131
  --- Changes   19 Feb 2003 23:55:22 -  1.130
  +++ Changes   20 Feb 2003 01:28:25 -  1.131
  @@ -10,6 +10,9 @@
   
   =item 1.99_09-dev
   
  +fix a bug for apr  0.9.3, where it segfaults in apr_uri_unparse, if
  +hostname is set, but not the scheme. [Stas]
  +
   move $r-send_http_header implementation to Apache::compat.  This
   allows the 1.0 code to run unmodified if $r-send_http_header is
   called before the response change. we already handle the check whether

cvs commit: modperl Changes

stas2003/02/19 21:21:56

  Modified:src/modules/perl Apache.xs
   .Changes
  Log:
  can't let the default typemap rule to convert sv into char* in
  unescape_url, since it doesn't handle correctly undefs (returns an
  unallocated  string, which then causes a segfault in
  ap_unescape_url. use SvPV_force, instead, which does the right
  thing.
  
  Revision  ChangesPath
  1.126 +5 -2  modperl/src/modules/perl/Apache.xs
  
  Index: Apache.xs
  ===
  RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
  retrieving revision 1.125
  retrieving revision 1.126
  diff -u -r1.125 -r1.126
  --- Apache.xs 6 Jul 2001 20:33:35 -   1.125
  +++ Apache.xs 20 Feb 2003 05:21:55 -  1.126
  @@ -655,8 +655,11 @@
   Apache r
   
   char *
  -unescape_url(string)
  -char *string
  +unescape_url(sv)
  +SV *sv
  +
  +INIT:
  +char *string = SvPV_force(sv, PL_na);
   
   CODE:
   unescape_url(string);
  
  
  
  1.662 +6 -0  modperl/Changes
  
  Index: Changes
  ===
  RCS file: /home/cvs/modperl/Changes,v
  retrieving revision 1.661
  retrieving revision 1.662
  diff -u -r1.661 -r1.662
  --- Changes   19 Feb 2003 02:38:21 -  1.661
  +++ Changes   20 Feb 2003 05:21:55 -  1.662
  @@ -10,6 +10,12 @@
   
   =item 1.27_01-dev
   
  +can't let the default typemap rule to convert sv into char* in
  +unescape_url, since it doesn't handle correctly undefs (returns an
  +unallocated  string, which then causes a segfault in
  +ap_unescape_url. use SvPV_force, instead, which does the right
  +thing. [Stas Bekman]
  +
   Make sure to start perl, if it's not running, before processing Perl*
   directives, with threaded perl and PERL_STACKED_HANDLERS=0 [Stas
   Bekman]

cvs commit: modperl/t/net/perl util.pl

stas2003/02/19 22:48:05

  Modified:t/net/perl util.pl
  Log:
  add tests for Apache::unescape_url
  
  Revision  ChangesPath
  1.16  +20 -1 modperl/t/net/perl/util.pl
  
  Index: util.pl
  ===
  RCS file: /home/cvs/modperl/t/net/perl/util.pl,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- util.pl   19 Jun 2002 16:31:52 -  1.15
  +++ util.pl   20 Feb 2003 06:48:04 -  1.16
  @@ -3,7 +3,7 @@
   use Apache::test;
   $|++;
   my $i = 0;
  -my $tests = 7;
  +my $tests = 9;
   
   my $r = shift;
   $r-send_http_header('text/plain');
  @@ -100,6 +100,25 @@
   Perl = sub { my $esc = URI::Escape::uri_escape($uri) },
   });  
   =cut
  +
  +{
  +my $str = aa%20dd%2epl;
  +my $expected = aa dd.pl;
  +my $received = Apache::unescape_url($str);
  +test ++$i, $received eq $expected;
  +print expected: $expected\n;
  +print received: $received\n;
  +}
  +
  +{
  +my $str = undef;
  +my $expected = ;
  +no warnings;
  +my $received = Apache::unescape_url($str);
  +test ++$i, $received eq $expected;
  +print expected: $expected\n;
  +print received: $received\n;
  +}
   
   $C = Apache::Util::ht_time();
   $Perl = HTTP::Date::time2str();

cvs commit: modperl/Apache Apache.pm

stas2003/02/19 22:52:10

  Modified:Apache   Apache.pm
  Log:
  add a note that the original string passed to Apache::unescape_url is
  mangled, so only the return value should be used.
  
  Revision  ChangesPath
  1.73  +6 -1  modperl/Apache/Apache.pm
  
  Index: Apache.pm
  ===
  RCS file: /home/cvs/modperl/Apache/Apache.pm,v
  retrieving revision 1.72
  retrieving revision 1.73
  diff -u -r1.72 -r1.73
  --- Apache.pm 13 Aug 2002 03:18:48 -  1.72
  +++ Apache.pm 20 Feb 2003 06:52:10 -  1.73
  @@ -1209,7 +1209,12 @@
   
   =item Apache::unescape_url($string)
   
  -Handy function for unescapes.  Use this one for filenames/paths.
  +  $unescaped_url = Apache::unescape_url($string)
  +
  +Handy function for unescapes.  Use this one for
  +filenames/paths. Notice that the original C$string is mangled in the
  +process (because it shrinks).
  +
   Use unescape_url_info for the result of submitted form data.
   
   =item Apache::unescape_url_info($string)

cvs commit: modperl/Apache Apache.pm

stas2003/02/19 22:54:23

  Modified:Apache   Apache.pm
  Log:
  add the reason why the variable gets rendered invalid on
  Apache::unescape_url
  
  Revision  ChangesPath
  1.74  +2 -1  modperl/Apache/Apache.pm
  
  Index: Apache.pm
  ===
  RCS file: /home/cvs/modperl/Apache/Apache.pm,v
  retrieving revision 1.73
  retrieving revision 1.74
  diff -u -r1.73 -r1.74
  --- Apache.pm 20 Feb 2003 06:52:10 -  1.73
  +++ Apache.pm 20 Feb 2003 06:54:23 -  1.74
  @@ -1213,7 +1213,8 @@
   
   Handy function for unescapes.  Use this one for
   filenames/paths. Notice that the original C$string is mangled in the
  -process (because it shrinks).
  +process (because the string part of PV shrinks, but the variable is
  +not updated, to speed things up).
   
   Use unescape_url_info for the result of submitted form data.

cvs commit: modperl/t/net/perl util.pl