Re: Confused

[Josef]

On Sun, Sep 22, 2002 at 10:33:36AM -0400, Rich DeSimone wrote:
 Hi I am just messing around with Perl DBI/Apache and I can't seem to understand this 
problem.  Right now I am just trying to write a simple CGI perl script that just 
displays a mysql query.  I am using this code...
 
 #!/usr/bin/perl -w
 
 use DBI;
 use CGI qw(fatalsToBrowser);
 
 print CGI::header();
 print titleTesting/title;
 print h1Teams list/h1br;
 
 my $dbh = DBI-connect(dbi:mysql:hello:localhost:3306, root, );
 my $sth1 = $dbh-prepare(select * from team1);
 
 $sth1-execute();
 while(my $team = $sth1-fetchrow_array()){
  print $teambr\n;}
 
 $dbh-disconnect;
 
 --
 Now when I run the file from a shell it queries the database properly and everything 
prints out fine.  The problem is when I put this file in cgi-bin and try to execute 
it via www I am getting an error and this is what the apache error_log is saying...
 
 [Sat Sep 21 18:21:08 2002] [error] [client 10.0.0.2] Premature end of script 
headers: football.pl
 [Sat Sep 21 18:21:08 2002] [error] [client 10.0.0.2] Can't locate loadable object 
for module DBI in INC (INC contains: /usr/local/lib/perl5/5.8.0/i686-linux 
/usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux 
/usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .) at 
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux/DBI.pm line 243

It sounds like you have two different versions of perl on your machine.  One
in /usr/bin and the other in /usr/local/bin.  Try comparing:

/usr/bin/perl -V
and
/usr/local/bin/perl -V

From there you can decide to get rid of the older perl if you want.

-josef

Re: Confused

[John Simpson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sunday 22 September 2002 10:33, Rich DeSimone wrote:
 [Sat Sep 21 18:21:08 2002] [error] [client 10.0.0.2] Can't locate
 loadable object for module DBI in @INC (@INC contains:
 /usr/local/lib/perl5/5.8.0/i686-linux
 /usr/local/lib/perl5/5.8.0
 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux
 /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .)
 at /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/DBI.pm line 243
 [Sat Sep 21 18:21:08 2002] [error] [client 10.0.0.2] BEGIN
 failed--compilation aborted at
 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/DBI.pm line 243.

howdy,

usually can't locate loadable object means it's looking for some kind of 
shared library (i.e. a .DLL or .so file) and either can't find it, or 
can't open it (permissions issues.) for DBI it may be looking for a 
shared library to access the specific database type you're using (such as 
libmysql.so or something similar- i would include a real filename but 
i'm at home and my dev boxes are at work behind the firewall.)

i would start by reading /usr/.../DBI.pm (where the error message is 
happening), look at line 243, and see if you can figure out what library 
it's trying to load. then figure out why it can't load, whether it's a 
permissions issue or a missing symlink or something.

also remember that the built-in @INC for mod_perl may not the same as the 
built-in @INC for your command-line perl interpreter. the list above is 
the built-in @INC for the mod_perl you're running, and running perl -V 
will show you the built-in @INC for your command-line perl.

if you've upgraded perl, DBI, or DBD::mysql since you compiled mod_perl, 
it may be looking for old library files that don't exist anymore.

you may also want to try running your httpd with the -X parameter, 
inside of a program like strace or ltrace, and read the output file to 
see what library it's trying to load. it can generate a LOT of output, 
but it will show you exactly what filename it's trying to open and what 
the error code was (i.e. ENOENT=file not found, EPERM=permissions, etc.)

try something like this:

ltrace -S -o trace.out /usr/sbin/httpd -X

you won't see anything extra on the screen while it's running, and it will 
run much more slowly than normal (you don't want to leave it running like 
this all the time.)

try hitting your script from a browser. after it doesn't work, go back to 
the console where this command is running and hit control-c to shut down 
httpd. read through the trace.out file and see if you can find the 
open() or dlopen() call that's failing. you may be able to use the time 
stamp from your error_log to find the right place in the trace output 
file.



some other things to try...

you may want to run ldconfig to rebuild your shared library cache and 
see if that helps (it doesn't hurt anything to run it whenever you feel 
like it.) start/restart your httpd after it finishes, and then try your 
script again.



if it's a permissions issue (and even if it's not) i have a script that i 
call pfix, which fixes permissions on the perl library directories. 
some CPAN modules, when you install them as root, install the files with 
root-only permissions. i run this script as a cron job every day, along 
with every time i install anything from CPAN. the script looks like this:

#!/bin/sh
chmod -R go=u-w /usr/lib/perl* /usr/local/lib/perl* /www/perl



sorry i can't be more help than this, i haven't switched to perl 5.8, 
apache 2, or mod_perl2 yet, which means i can't do a live test myself.

- -- 
- 
| John Simpson Programmer at Large |
| [EMAIL PROTECTED] http://www.jms1.net/ |
- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9joyjEB9RczMG/PsRArJJAJ9RWpzHiE6uCWeDIS0JMfK2gMHm4gCgqqcW
2ueAGIytfnWhapbMcXwDteE=
=Skl2
-END PGP SIGNATURE-

Re: Confused

[Rich DeSimone]

I have no idea why but it works all of a sudden.  I didn't do one thing.
How strange is thatthanks for your help guys I did learn some stuff.

Rich

- Original Message -
From: John Simpson [EMAIL PROTECTED]
To: Rich DeSimone [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, September 22, 2002 11:38 PM
Subject: Re: Confused


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sunday 22 September 2002 10:33, Rich DeSimone wrote:
 [Sat Sep 21 18:21:08 2002] [error] [client 10.0.0.2] Can't locate
 loadable object for module DBI in @INC (@INC contains:
 /usr/local/lib/perl5/5.8.0/i686-linux
 /usr/local/lib/perl5/5.8.0
 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux
 /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .)
 at /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/DBI.pm line 243
 [Sat Sep 21 18:21:08 2002] [error] [client 10.0.0.2] BEGIN
 failed--compilation aborted at
 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/DBI.pm line 243.

howdy,

usually can't locate loadable object means it's looking for some kind of
shared library (i.e. a .DLL or .so file) and either can't find it, or
can't open it (permissions issues.) for DBI it may be looking for a
shared library to access the specific database type you're using (such as
libmysql.so or something similar- i would include a real filename but
i'm at home and my dev boxes are at work behind the firewall.)

i would start by reading /usr/.../DBI.pm (where the error message is
happening), look at line 243, and see if you can figure out what library
it's trying to load. then figure out why it can't load, whether it's a
permissions issue or a missing symlink or something.

also remember that the built-in @INC for mod_perl may not the same as the
built-in @INC for your command-line perl interpreter. the list above is
the built-in @INC for the mod_perl you're running, and running perl -V
will show you the built-in @INC for your command-line perl.

if you've upgraded perl, DBI, or DBD::mysql since you compiled mod_perl,
it may be looking for old library files that don't exist anymore.

you may also want to try running your httpd with the -X parameter,
inside of a program like strace or ltrace, and read the output file to
see what library it's trying to load. it can generate a LOT of output,
but it will show you exactly what filename it's trying to open and what
the error code was (i.e. ENOENT=file not found, EPERM=permissions, etc.)

try something like this:

ltrace -S -o trace.out /usr/sbin/httpd -X

you won't see anything extra on the screen while it's running, and it will
run much more slowly than normal (you don't want to leave it running like
this all the time.)

try hitting your script from a browser. after it doesn't work, go back to
the console where this command is running and hit control-c to shut down
httpd. read through the trace.out file and see if you can find the
open() or dlopen() call that's failing. you may be able to use the time
stamp from your error_log to find the right place in the trace output
file.



some other things to try...

you may want to run ldconfig to rebuild your shared library cache and
see if that helps (it doesn't hurt anything to run it whenever you feel
like it.) start/restart your httpd after it finishes, and then try your
script again.



if it's a permissions issue (and even if it's not) i have a script that i
call pfix, which fixes permissions on the perl library directories.
some CPAN modules, when you install them as root, install the files with
root-only permissions. i run this script as a cron job every day, along
with every time i install anything from CPAN. the script looks like this:

#!/bin/sh
chmod -R go=u-w /usr/lib/perl* /usr/local/lib/perl* /www/perl



sorry i can't be more help than this, i haven't switched to perl 5.8,
apache 2, or mod_perl2 yet, which means i can't do a live test myself.

- --
- 
| John Simpson Programmer at Large |
| [EMAIL PROTECTED] http://www.jms1.net/ |
- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9joyjEB9RczMG/PsRArJJAJ9RWpzHiE6uCWeDIS0JMfK2gMHm4gCgqqcW
2ueAGIytfnWhapbMcXwDteE=
=Skl2
-END PGP SIGNATURE-

Confused

[Rich DeSimone]

Hi I am just messing around with Perl DBI/Apache 
and I can't seem to understand this problem. Right now I am just trying to 
write a simple CGI perl script that just displays a mysql query. I am 
using this code...

#!/usr/bin/perl -w

use DBI;use CGI 
qw(fatalsToBrowser);

print CGI::header();print 
"titleTesting/title";print "h1Teams 
list/h1br";

my $dbh = 
DBI-connect("dbi:mysql:hello:localhost:3306", "root", "");my $sth1 = 
$dbh-prepare("select * from team1");

$sth1-execute();while(my $team = 
$sth1-fetchrow_array()){print "$teambr\n";}

$dbh-disconnect;

--
Now when I run the file from a shell it queries 
the database properly and everything prints out fine. The problem is when 
I put this file in cgi-bin and try to execute it via www I am getting an error 
and this is what the apache error_log is saying...

[Sat Sep 21 18:21:08 2002] [error] [client 
10.0.0.2] Premature end of script headers: football.pl[Sat Sep 21 18:21:08 
2002] [error] [client 10.0.0.2] Can't locate loadable object for module DBI in 
@INC (@INC contains: /usr/local/lib/perl5/5.8.0/i686-linux 
/usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux 
/usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .) at 
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux/DBI.pm line 243[Sat Sep 21 
18:21:08 2002] [error] [client 10.0.0.2] BEGIN failed--compilation aborted at 
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux/DBI.pm line 243.[Sat Sep 21 
18:21:08 2002] [error] [client 10.0.0.2] Compilation failed in require at 
/usr/local/apache2/cgi-bin/football.pl line 3.[Sat Sep 21 18:21:08 2002] 
[error] [client 10.0.0.2] BEGIN failed--compilation aborted at 
/usr/local/apache2/cgi-bin/football.pl line 3.

Regular perl scripts (non DBI) run fine so I 
don't know if there is something special didn't set up. I am running the 
latest stable apache2 and mod_perl. I installed Apache::DBI as well and 
the README says "For Apache::DBI you need to enable the appropriate call-back 
hooks when making mod_perl: perl Makefile.PL 
PERL_CHILD_INIT=1 PERL_STACKED_HANDLERS=1." I tried that but the latest 
mod_perl doesn't recognize those parameters. Maybe that could have 
something to do with it? 

I am sorry if this is 
an obvious answer (IE I didn't read the FAQs thoroughly enough) but I am new to 
this stuff and some of that info can be overwhelming at times. Also I hope 
this is the right mailing list because it seems to be a mod_perl related 
problem

Thanks,

Rich
[EMAIL PROTECTED]

Re: $r-path_info() getting confused

[giorgos zervas]

hi there,

someone asked a similar question a while ago and here the answer that i 
gave them... i think it answers your question too.

 START 

apache uses a simple technique for determining the path_info. it starts 
at your document root and looks for the directory you specified in your 
URI. it continues to go deeper in the directory structure until it 
encounters a directory(or file) that doesn't exist. when this happens 
the path_info is set to rest of the URI (not including the last part 
which wasn't found!).

so in your case apache looks for $DOCROOT/debug

this doesn't exist (presumably) in your $DOCROOT. so the path_info is 
set to whatever is left, ie nothing!

if you tried to request www.host/debug/foo

the path_info would be /foo (without the /debug part)

if you created a directory called debug inside you docroot and you tried 
the previous example then you path_info would be empty.

i hope this doesn't confuse you a a lot!

- END 

in your example you request /rms/module/foo

apache looks for /rms in your docroot and /rms is not found.

consequently the path_info is set to the remaining part of the URI, ie 
/module/foo

apache doesn't take into consideration Location directives when setting 
the path_info as far as i know.

best regards,
giorgos

Fran Fabrizio wrote:
 
 In my conf file, I have the following directives:
 
 Location /rms
AuthType Apache::AuthCookieRMSDBI
AuthName RMS
PerlAuthenHandler Apache::AuthCookieRMSDBI-authenticate
PerlAuthzHandler Apache::AuthCookieRMSDBI-authorize
require valid-user
 /Location
 
 Location /rms/module
  SetHandler perl-script
  PerlHandler RMS::Control::Module-handler
 /Location
 
 When I call the URL /rms/module/foo, and in 
 RMS::Control::Module-handler I examine $r-path_info, I get as a value 
 '/module/foo' rather than the expected '/foo'.  If apache recognized 
 that /rms/module/foo was to go to RMS::Control::Module-handler then it 
 knows that /rms/module is the script name and thus should know that 
 path_info should be just /foo, right?
 
 Thanks,
 Fran

$r-path_info() getting confused

[Fran Fabrizio]

In my conf file, I have the following directives:

Location /rms
AuthType Apache::AuthCookieRMSDBI
AuthName RMS
PerlAuthenHandler Apache::AuthCookieRMSDBI-authenticate
PerlAuthzHandler Apache::AuthCookieRMSDBI-authorize
require valid-user
 /Location

Location /rms/module
  SetHandler perl-script
  PerlHandler RMS::Control::Module-handler
/Location

When I call the URL /rms/module/foo, and in 
RMS::Control::Module-handler I examine $r-path_info, I get as a value 
'/module/foo' rather than the expected '/foo'.  If apache recognized 
that /rms/module/foo was to go to RMS::Control::Module-handler then it 
knows that /rms/module is the script name and thus should know that 
path_info should be just /foo, right?

Thanks,
Fran

Re: $r-path_info() getting confused

[Geoffrey Young]

Fran Fabrizio wrote:

 
 In my conf file, I have the following directives:
 
 Location /rms
AuthType Apache::AuthCookieRMSDBI
AuthName RMS
PerlAuthenHandler Apache::AuthCookieRMSDBI-authenticate
PerlAuthzHandler Apache::AuthCookieRMSDBI-authorize
require valid-user
 /Location
 
 Location /rms/module
  SetHandler perl-script
  PerlHandler RMS::Control::Module-handler
 /Location
 
 When I call the URL /rms/module/foo, and in 
 RMS::Control::Module-handler I examine $r-path_info, I get as a value 
 '/module/foo' rather than the expected '/foo'.  If apache recognized 
 that /rms/module/foo was to go to RMS::Control::Module-handler then it 
 knows that /rms/module is the script name and thus should know that 
 path_info should be just /foo, right?


we illustrate this in the cookbook on pp 156-157.

I'm not exactly sure why this happens internally, but its an Apache 
thing and not a mod_perl thing.  An Alias directive will probably set 
things straight for you.

--Geoff

Re: $r-path_info() getting confused

[darren chamberlain]

* Fran Fabrizio [EMAIL PROTECTED] [2002-08-21 11:03]:
 Location /rms
 /Location
 
 Location /rms/module
 /Location
 
 When I call the URL /rms/module/foo, and in 
 RMS::Control::Module-handler I examine $r-path_info, I get as a value 
 '/module/foo' rather than the expected '/foo'.  If apache recognized 
 that /rms/module/foo was to go to RMS::Control::Module-handler then it 
 knows that /rms/module is the script name and thus should know that 
 path_info should be just /foo, right?

I would hazard a guess that /rms exists under the document root, but
/rms/modules does not.  How path_info is created has more to do with
what the filesystem looks like than what the Location blocks look like.

(darren)

-- 
What is ideology but the rationalisation of a vested interest?

[BUG] mod_perl confused about method calls when using internal_redirect

[Philippe Troin]

I've found that mod_perl can get confused when dealing with method
calls during a redirect_internal phase:

 1. page /1 uses method calls, and works when accessed as /1

 2. an other page /R uses internal_redirect to go to /1, and mod_perl
fails with an undefined subroutine error.

This has been seen on:

  apache 1.3.9-14, perl 5.004.05-1.1, and mod_perl 1.25-3 (Debian potato)

and on:

  apache 1.3.22-2.1, perl 5.6.1-6, and mod_perl 1.26-1 (Debian woody/testing)

How to reproduce:

Use this startup.pl file:

==
# Common
package Common;

use Apache::Constants qw(:common);

sub handler($$)
  {
my $self = shift;
my $req = shift;
$req-content_type('text/plain');
$req-send_http_header();
$req-print($self-doit());
return OK;
  }

sub doit
  {
return COMMON;
  }

# Common::Impl1
package Common::Impl1;

@ISA=qw(Common);

sub doit
  {
return IMPL1\n;
  }

# Common::Impl2;
package Common::Impl2;

@ISA=qw(Common);

sub doit
  {
return IMPL2\n;
  }

# Redir
package Redir;

use Apache::Constants qw(:common);

sub handler
  {
my $req = shift;
$req-internal_redirect(/1);
return OK;
  }

1;
==

PerlRequire the above, and use the following apache configuration:

==
Location /0
  Order allow,deny
  Allow from all
  SetHandler perl-script
  PerlHandler Common
/Location

Location /1
  Order allow,deny
  Allow from all
  SetHandler perl-script
  PerlHandler Common::Impl1
/Location

Location /2
  Order allow,deny
  Allow from all
  SetHandler perl-script
  PerlHandler Common::Impl2
/Location

Location /R
  Order allow,deny
  Allow from all
  SetHandler perl-script
  PerlHandler Redir
/Location

PerlRequire startup.pl
==

Then, directing a web browser to /0 prints COMMON, to /1 prints IMPL1,
to /2 prints IMPL2, as expectected.

Similarly, when pointing to /R (which redirects internally to /1),
IMPL1 should appear.

However, I get a 500 Internal server error and this in the logs:

[error] Undefined subroutine Common::Impl1::handler called at
startup.pl line 49.

I've tried to debug the problem, and the problem lies inside 
perl_handler_ismethod() in src/modules/perl/mod_perl.c: it returns
different values when called from inside the internal_redirect than
called without internal_redirect.

Inside perl_handler_ismethod():

if(!sub) return 0;
sv = newSVpv(sub,0);
if(!(cv = sv_2cv(sv, stash, gv, FALSE))) {
GV *gvp = gv_fetchmethod(pclass, sub);
if (gvp) cv = GvCV(gvp);

sv_2cv() returns different values when called from inside an
internal_redirect than called without
internal_redirect. Unfortunately, I could not grok sv_2cv(). It's not
even documented in the perl docs.

Phil.

confused and need help

[John Michael]

Hi
I wanted to update my apache and mod-perl install.
I stated to do it and found that I needed the LWP module which requires 
some other modules first.
I got allof them on untill I needed the libnet module.
ALl of the other modules I installed by hand and having no problems until I 
needed the libnet module.I could only find it in the Bundle::libnet module 
and thathas to be run from the CPAN module. In an attempt to install 
Bundle::libnet which you have to do through CPAN it seems that CPAN installed 
another version of perl on my server in 
usr/local/lib/perl5/5.6.1
I already havea version in 
usr/lib/perl5/5.6.0

Did it automatically try to update my version?

When I run 
perl -MCPAN -e shell
it is being run from the 5.6.1 version at usr/local and therefore does not 
find any of the other modules I already have installed.
I know this because it uses the cpan config file in that location and also 
the dependencies that it is showing are already installed in the other 
location.

Can I just delete the 5.6.1 version off of my server?

How do I get the 5.6.0 version of cpan to run and the server to recognize 
this?

Also, I am running a mod-perl server and have many scripts running under 
it.
How does the server know which version to use?

Am I going to have some problems?

I'm not sure what to do at this point and don't know where to look.

I now have to versions of perl on my server. I assume there is a file 
somewhere that tells the computer which one to use when you type perl from the 
command line. What should I do?

Thanks
John Michel

Re: confused and need help

[Ged Haywood]

Hi there,

On Sat, 12 Jan 2002, John Michael wrote:

 I wanted to update my apache and mod-perl install.

H.  I take it you had a good reason for doing this?

 I stated to do it and [snip]
 usr/local/lib/perl5/5.6.1
 I already have a version in 
 usr/lib/perl5/5.6.0
 
 Did it automatically try to update my version?

Yes.  Don't worry, 5.6.1 is better than 5.6.0 - a lot better.
But if you get the latest version of CPAN.pm it won't do that
any more.

 When I run perl -MCPAN -e shell it is being run from the 5.6.1
 version at usr/local and therefore does not find any of the other
 modules I already have installed.

It might be best to install the latest CPAN.pm and use that to install
everything you need again.  It won't take long and you will know then
that the installation is reliable.  Then grab the source tarballs and
rebuild Apache and modperl from scratch, recompiling as per the
instructions in the Guide http://perl.apache.org/guide.  You don't
say waht versions of Apache and mod_perl you were using, so I don't
know how much configuration work will be necessary.

 Can I just delete the 5.6.1 version off of my server?

Don't do that.

 How do I get the 5.6.0 version of cpan to run and the server to recognize this?

There is no version 5.6.0 of CPAN.pm, my versions are around 1.58/1.59
depending on the machine.  It's a Perl module which can run with a
number of different versions of Perl.  I use Perl versions 5.005_03
and 5.7.0, I had trouble with 5.6.0 and started using 5.7.0 for that
reason.  5.6.0 wasn't out when I grabbed 5.7.0, but I've had no real
troubles with 5.7.0 even on fairly big systems.

 Also, I am running a mod-perl server and have many scripts running under it.
 How does the server know which version to use?

That's set when you compile mod_perl.  Read the Guide and the Eagle Book
(Writing Apache Modules with Perl and C, ISBN 1-56592-567-X).

 Am I going to have some problems?

Only if you don't stop and think about what you're doing.

requre,use, modules, namespace...I'm confused...

[swade]

Hi,
 I've read the docs on traps in using require and 
use, etc in mod_perl...I'm confused
heres what I'm trying to figure out...

lets say I have 3 sites on 1 box. so I have /home/httpd/site1 
/home/httpd/site2 /home/httpd/site3

each of them host the same scripts. so if my script is test.cgi 
/home/httpd/site1/cgi-bin/test.cgi
/home/httpd/site2/cgi-bin/test.cgi
etc

Now without mod_perl I have a file called configure.cgi in 
/home/httpd/site1/cgi-bin/configure.cgi
etc...for other sites. each configure script is setup differently according 
to the site.


usually I would do, require "configure.cgi" in the test.cgi script; but 
it's my understanding this won't work in mod_perl

what I'm trying to do is figure out how to have test.cgi the same...and 
pull what it needs from the 
configure file. So that when I update test.cgi I can ftp it to all the 
sites without having to change it for
each site. For the life of me I cannot figure out how it's done in mod_perl 
without having namespace problems...

I read that you should use a module, but then I understand you cannot have 
modules with the same name.I readyou could alsogive package 
name in the configure.cgi script..like package config; Will that have the same 
namespace problem? Is there some info on how to do this someone could point me 
to?

thanks,
shawn

RE: requre,use, modules, namespace...I'm confused...

[Wang Xingyu []]

 I have same question.And my solution:

1.In httpd.conf
PerlAddVar  conf /home/httpd/site1/cgi-bin/configure.cgi 
PerlAddVar  conf /home/httpd/site2/cgi-bin/configure.cgi
PerlAddVar  conf /home/httpd/site3/cgi-bin/configure.cgi

2.In your test.cgi
 use vars qw(%conf);
 my $site = $ENV{'HTTP_HOST'};
# get site1,site2,etc.
($site) = ($site =~ /^\/(.*?)\.some\.dom\/cgi-bin\/i);
use Apache;
my $r = Apache-request();
my @conf_file = $r-dir_config-get('conf');
foreach (@conf_file)
{
# import all site configuration file
require;
}
no strict qw(refs);
# import configure variable
# call by $conf{'SOME_VAR'};
*conf = \%{${conf::.$site.::conf}};
3.In your site1 configure.cgi,use ref of hash
package conf::site1;
$conf =
{
# web name.
'web_name' = 'site1',
# Parent web link.
'web_link' = 'http://site1.some.dom/',
}
# in different configure.cgi,have different configure variable and
package.


And ,Please referer http://perl.apache.org/guide/,and thanks stas and
other.


-Original Message-
From: swade [mailto:[EMAIL PROTECTED]] 
Sent: 2001Äê7ÔÂ2ÈÕ 13:18
To: [EMAIL PROTECTED]
Subject: requre,use, modules, namespace...I'm confused...


Hi,
 I've read the docs on traps in using require and use, etc in
mod_perl...I'm confused
heres what I'm trying to figure out...

lets say I have 3 sites on 1 box. so I have /home/httpd/site1
/home/httpd/site2 /home/httpd/site3

each of them host the same scripts. so if my script is test.cgi 
/home/httpd/site1/cgi-bin/test.cgi
/home/httpd/site2/cgi-bin/test.cgi
etc

Now without mod_perl I have a file called configure.cgi in 
/home/httpd/site1/cgi-bin/configure.cgi
etc...for other sites. each configure script is setup differently
according to the site.

usually I would do, require configure.cgi in the test.cgi script; but
it's my understanding this won't work in mod_perl

what I'm trying to do is figure out how to have test.cgi the same...and
pull what it needs from the 
configure file. So that when I update test.cgi I can ftp it to all the
sites without having to change it for
each site. For the life of me I cannot figure out how it's done in
mod_perl without having namespace problems...

I read that you should use a module, but then I understand you cannot
have modules with the same name. I read you could also give package name
in the configure.cgi script..like package config; Will that have the
same namespace problem? Is there some info on how to do this someone
could point me to?

thanks,
shawn