a require problem

------=_Part_19002_9590728.1220018094173
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I have began a project, but meet some problems,:)

say there are three dirs:

|- cgi-bin
|- cgi-bin - lib
|- cgi-bin - template


I have a script in cgi-bin, which requires the template file from template =
dir.
This script also uses a library file (.pm) from lib dir.
Finally the library need to require the former template file too.

say the script is myscr.pl, the lib file is mylib.pm, the template file is =
myttt.tmpl.

so in myscr.pl:

use lib './lib';
use mylib;
require 'template/myttt.tmpl';


in mylib.pm:

require '../template/myttt.tmpl';


When I execute "perl mysrc.pl", it can't run, saying the routines in myttt.=
tmpl can't be found.


How to fixup it? thanks.


Regards,
Jeff.

Créez votre adresse électronique prenom.nom@laposte.net=20
1 Go d'espace de stockage, anti-spam et anti-virus intégrés.

------=_Part_19002_9590728.1220018094173
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I have began a project, but meet some problems,:)<=
br />
say there are three dirs:

|- cgi-bin
|- cgi-bin =
- lib
|- cgi-bin - template


I have a script in cgi-bi=
n, which requires the template file from template dir.
This script als=
o uses a library file (.pm) from lib dir.
Finally the library need to =
require the former template file too.

say the script is myscr.pl=
, the lib file is mylib.pm, the template file is myttt.tmpl.

so =
in myscr.pl:

use lib './lib';
use mylib;
require 'temp=
late/myttt.tmpl';


in mylib.pm:

require '../temp=
late/myttt.tmpl';


When I execute "perl mysrc.pl"=
, it can't run, saying the routines in myttt.tmpl can't be found.

/>
How to fixup it? thanks.


Regards,
Jeff.

RE: a require problem

Is this not a current-working-directory issue?

This isn't terribly well documented on the mod_perl site, but from
http://perl.apache.org/docs/2.0/api/ModPerl/Registry.html


META: document that for now we don't chdir() into the script's
dir, because it affects the whole process under threads.
ModPerl::RegistryPrefork should be used by those who run only
under prefork MPM.

Try using absolute paths for 'use lib', instead of : use lib './lib'

clint

On Fri, 2008-08-29 at 10:53 -0400, Berg, Eric wrote:
> Jeff,
>
> I'm running into issues with mod_perl2 that sound like they may be
> related. Are you, in fact, running this script under mod_perl? Doesthe
> myttt.tmpl file that you refer to contain Perl code that is to be
> eval'ed in your myscr.pl?
>
> Just yesterday I ran into a problem in which using do( $file ) or eval(
> $file ) both had problems in that they did not successfully execute the
> code in $file.
>
> Does that sound like your problem?
>
> Folks, is there some kind of setting for mod_perl2 that affects this, or
> a different way to accomplish this?
>
> Eric
>
> > -----Original Message-----
> > From: seandavi@gmail.com [mailto:seandavi@gmail.com] On
> > Behalf Of Sean Davis
> > Sent: Friday, August 29, 2008 10:05 AM
> > To: Jeff Pang
> > Cc: modperl perl apache org
> > Subject: Re: a require problem
> >
> > On Fri, Aug 29, 2008 at 9:54 AM, Jeff Pang wrote:
> > > I have began a project, but meet some problems,:)
> > >
> > > say there are three dirs:
> > >
> > > |- cgi-bin
> > > |- cgi-bin - lib
> > > |- cgi-bin - template
> > >
> > >
> > > I have a script in cgi-bin, which requires the template
> > file from template
> > > dir.
> > > This script also uses a library file (.pm) from lib dir.
> > > Finally the library need to require the former template file too.
> > >
> > > say the script is myscr.pl, the lib file is mylib.pm, the
> > template file is
> > > myttt.tmpl.
> > >
> > > so in myscr.pl:
> > >
> > > use lib './lib';
> > > use mylib;
> > > require 'template/myttt.tmpl';
> > >
> > >
> > > in mylib.pm:
> > >
> > > require '../template/myttt.tmpl';
> > >
> > >
> > > When I execute "perl mysrc.pl", it can't run, saying the routines in
> > > myttt.tmpl can't be found.
> >
> > Hi, Jeff. This list is for mod_perl development, not CGI. That said,
> > you'll need to read the documentation for the template engine (which
> > one are you using?) that you are using. I doubt that you want to
> > simply "require" them in your script like this.
> >
> > Sean
> >

RE: a require problem

Not for me. I hit the pwd issue early on in my (currently incredibly
frustrating and dubious-to-the-point-of-abandonment) migration to Apache
2.2.=20

It doesn't sound like that's Jeff's problem either; he says that the
routines can't be found, not the file.

E

> -----Original Message-----
> From: Clinton Gormley =5Bmailto:clint=40traveljury.com]
> Sent: Friday, August 29, 2008 11:19 AM
> To: Berg, Eric
> Cc: Sean Davis; Jeff Pang; modperl perl apache org
> Subject: RE: a require problem
>=20
> Is this not a current-working-directory issue?
>=20
> This isn't terribly well documented on the mod_perl site, but from=20
> http://perl.apache.org/docs/2.0/api/ModPerl/Registry.html
>=20
>=20
> META: document that for now we don't chdir() into the script's
> dir, because it affects the whole process under threads.
> ModPerl::RegistryPrefork should be used by those who run only
> under prefork MPM.
> =20
> Try using absolute paths for 'use lib', instead of : use lib './lib'=20
>=20
> clint
>=20
> On Fri, 2008-08-29 at 10:53 -0400, Berg, Eric wrote:
> > Jeff,
> >=20
> > I'm running into issues with mod_perl2 that sound like they may be
> > related. Are you, in fact, running this script under=20
> > mod_perl? Doesthe
> > myttt.tmpl file that you refer to contain Perl code that is to be
> > eval'ed in your myscr.pl?
> >=20
> > Just yesterday I ran into a problem in which using do(=20
> > =24file ) or eval(=24file ) both had problems in that they did=20
> > not successfully execute the code in =24file.
> >=20
> > Does that sound like your problem?
> >=20
> > Folks, is there some kind of setting for mod_perl2 that affects
this, or
> > a different way to accomplish this?
> >=20
> > Eric
> >=20
> > > -----Original Message-----
> > > From: seandavi=40gmail.com =5Bmailto:seandavi=40gmail.com=5D On=20
> > > Behalf Of Sean Davis
> > > Sent: Friday, August 29, 2008 10:05 AM
> > > To: Jeff Pang
> > > Cc: modperl perl apache org
> > > Subject: Re: a require problem
> > >=20
> > > On Fri, Aug 29, 2008 at 9:54 AM, Jeff Pang=20
> wrote:
> > > > I have began a project, but meet some problems,:)
> > > >
> > > > say there are three dirs:
> > > >
> > > > =7C- cgi-bin
> > > > =7C- cgi-bin - lib
> > > > =7C- cgi-bin - template
> > > >
> > > >
> > > > I have a script in cgi-bin, which requires the template=20
> > > file from template
> > > > dir.
> > > > This script also uses a library file (.pm) from lib dir.
> > > > Finally the library need to require the former template=20
> file too.
> > > >
> > > > say the script is myscr.pl, the lib file is mylib.pm, the=20
> > > template file is
> > > > myttt.tmpl.
> > > >
> > > > so in myscr.pl:
> > > >
> > > > use lib './lib';
> > > > use mylib;
> > > > require 'template/myttt.tmpl';
> > > >
> > > >
> > > > in mylib.pm:
> > > >
> > > > require '../template/myttt.tmpl';
> > > >
> > > >
> > > > When I execute =22perl mysrc.pl=22, it can't run, saying=20
> the routines in
> > > > myttt.tmpl can't be found.
> > >=20
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - =
- - - - - - -

This message is intended only for the personal and confidential use of the =
designated recipient(s) named above. If you are not the intended =
recipient of this message you are hereby notified that any review, =
dissemination, distribution or copying of this message is strictly =
prohibited. This communication is for information purposes only and =
should not be regarded as an offer to sell or as a solicitation of an =
offer to buy any financial product, an official confirmation of any =
transaction, or as an official statement of Lehman Brothers. Email =
transmission cannot be guaranteed to be secure or error-free. Therefore, =
we do not represent that this information is complete or accurate and it =
should not be relied upon as such. All information is subject to change =
without notice.

--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within =
this communication (including any attachments) is not intended or written =
to be used and cannot be used for the purpose of (i) avoiding U.S. tax =
related penalties or (ii) promoting, marketing or recommending to another =
party any transaction or matter addressed herein.

Re: a require problem

On Fri, Aug 29, 2008 at 10:53 AM, Berg, Eric wrote:
> Just yesterday I ran into a problem in which using do( $file ) or eval(
> $file ) both had problems in that they did not successfully execute the
> code in $file.

What were the error messages from do and eval?

> Folks, is there some kind of setting for mod_perl2 that affects this, or
> a different way to accomplish this?

It doesn't sound like any issue I've heard of, but it's really hard to
say without the error message.

- Perrin

Re: a require problem

On Fri, Aug 29, 2008 at 11:46 AM, Perrin Harkins wrote:
> On Fri, Aug 29, 2008 at 10:53 AM, Berg, Eric wrote:

>> eval( $file ) ... did not successfully execute the code in $file.

that isn't supposed to. eval( `cat $file`) should though. Or

use Tie::Slurp;
tie my $readfile, Tie::Slurp::Readonly => $file;
eval $readfile;

--
off-topic notices are almost universally, themselves, off topic.

Re: a require problem

On Fri, Aug 29, 2008 at 11:19 AM, Clinton Gormley wrote:
> Is this not a current-working-directory issue?
>
> This isn't terribly well documented on the mod_perl site, but from
> http://perl.apache.org/docs/2.0/api/ModPerl/Registry.html

Better documented here:
http://perl.apache.org/docs/2.0/user/porting/compat.html#C_A pache__Registry___C_Apache__PerlRun__and_Friends

> Try using absolute paths for 'use lib', instead of : use lib './lib'

Or use ModPerl::RegistryPrefork.

- Perrin

RE: a require problem

That was part of the problem, Perrin: there were no error messages.

Turns out that this is what's happening:

The required file does, in fact, execute, so that's NOT the problem.

It's a separate problem that manifests itself when using the -x file
test.

The included/do()'ed file contains an array of commands and an array of
paths -- BTW, I'm working with cvsweb
(http://www.freebsd.org/projects/cvsweb.html) -- and there's code in
there that finds a valid full path like this:

=24cmd =3D 'enscript';
=24full_path{$cmd=7D =3D search_path( =24cmd);

sub search_path(=24) =7B
my (=24command) =3D =40_;
for my =24d (=40command_path) =7B
my =24cmd =3D catfile( =24d, =24command );
return =24cmd if ( -x =24cmd && =21-d _ );
=7D
return '';
=7D

The really weird thing is that when run in a CGI context, the -x test
works as expected, but when called when running as a mod_perl2 registry
script, it returns false, even though the file (that does exist) is
executable by everyone. Change it back to CGI (not mod_perl) and the
same code does work properly.

Sorry for the confusion about the actual cause of the problem.

Eric=20

> -----Original Message-----
> From: pharkins=40gmail.com =5Bmailto:pharkins=40gmail.com=5D On=20
> Behalf Of Perrin Harkins
> Sent: Friday, August 29, 2008 12:46 PM
> To: Berg, Eric
> Cc: Sean Davis; Jeff Pang; modperl perl apache org
> Subject: Re: a require problem
>=20
> On Fri, Aug 29, 2008 at 10:53 AM, Berg, Eric=20
> wrote:
> > Just yesterday I ran into a problem in which using do(=20
> =24file ) or eval(
> > =24file ) both had problems in that they did not successfully=20
> execute the
> > code in =24file.
>=20
> What were the error messages from do and eval?
>=20
> > Folks, is there some kind of setting for mod_perl2 that=20
> affects this, or
> > a different way to accomplish this?
>=20
> It doesn't sound like any issue I've heard of, but it's really hard to
> say without the error message.
>=20
> - Perrin
>=20
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - =
- - - - - - -

This message is intended only for the personal and confidential use of the =
designated recipient(s) named above. If you are not the intended =
recipient of this message you are hereby notified that any review, =
dissemination, distribution or copying of this message is strictly =
prohibited. This communication is for information purposes only and =
should not be regarded as an offer to sell or as a solicitation of an =
offer to buy any financial product, an official confirmation of any =
transaction, or as an official statement of Lehman Brothers. Email =
transmission cannot be guaranteed to be secure or error-free. Therefore, =
we do not represent that this information is complete or accurate and it =
should not be relied upon as such. All information is subject to change =
without notice.

--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within =
this communication (including any attachments) is not intended or written =
to be used and cannot be used for the purpose of (i) avoiding U.S. tax =
related penalties or (ii) promoting, marketing or recommending to another =
party any transaction or matter addressed herein.

Re: a require problem

On Fri, Aug 29, 2008 at 1:23 PM, Berg, Eric wrote:
> The really weird thing is that when run in a CGI context, the -x test
> works as expected, but when called when running as a mod_perl2 registry
> script, it returns false, even though the file (that does exist) is
> executable by everyone. Change it back to CGI (not mod_perl) and the
> same code does work properly.

It's still most likely a permissions issue. I'd suggest trying to
execute it as the user who your mod_perl server runs as.

- Perrin

RE: a require problem

The mod_perl server and the CGI server are the same. It's just a
handler configured for CGI's for *.cgi and mod_perl for *.pl, and I've
symlinked from a .pl to the .cgi.

The web server for CGI and mod_perl and the command line run were all
done as the same user.

Code like this:

warn "$cmd is =22 . (-x =24cmd ? "" : =22 not=22) .=22 =
EXECUTABLE=5Cn=22 ;
warn =60ls -l =24cmd=60;

Yields this under mod_perl:

/usr/bin/rcsdiff is not EXECUTABLE
-rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff

and this from the command line and

/usr/bin/rcsdiff is EXECUTABLE
-rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff

and in a CGI:

/usr/bin/rcsdiff is EXECUTABLE
-rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff

Same server, CGI vs mod_perl, different behavior.

Probably not permissions. But what?

Eric

> -----Original Message-----
> From: pharkins=40gmail.com =5Bmailto:pharkins=40gmail.com=5D On=20
> Behalf Of Perrin Harkins
> Sent: Friday, August 29, 2008 1:35 PM
> To: Berg, Eric
> Cc: Sean Davis; Jeff Pang; modperl perl apache org
> Subject: Re: a require problem
>=20
> On Fri, Aug 29, 2008 at 1:23 PM, Berg, Eric=20
> wrote:
> > The really weird thing is that when run in a CGI context,=20
> the -x test
> > works as expected, but when called when running as a=20
> mod_perl2 registry
> > script, it returns false, even though the file (that does exist) is
> > executable by everyone. Change it back to CGI (not=20
> mod_perl) and the
> > same code does work properly.
>=20
> It's still most likely a permissions issue. I'd suggest trying to
> execute it as the user who your mod_perl server runs as.
>=20
> - Perrin
>=20
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - =
- - - - - - -

This message is intended only for the personal and confidential use of the =
designated recipient(s) named above. If you are not the intended =
recipient of this message you are hereby notified that any review, =
dissemination, distribution or copying of this message is strictly =
prohibited. This communication is for information purposes only and =
should not be regarded as an offer to sell or as a solicitation of an =
offer to buy any financial product, an official confirmation of any =
transaction, or as an official statement of Lehman Brothers. Email =
transmission cannot be guaranteed to be secure or error-free. Therefore, =
we do not represent that this information is complete or accurate and it =
should not be relied upon as such. All information is subject to change =
without notice.

--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within =
this communication (including any attachments) is not intended or written =
to be used and cannot be used for the purpose of (i) avoiding U.S. tax =
related penalties or (ii) promoting, marketing or recommending to another =
party any transaction or matter addressed herein.

Re: a require problem

On Fri, Aug 29, 2008 at 2:04 PM, Berg, Eric wrote:
> The mod_perl server and the CGI server are the same.

Even so, CGI is often configured to execute the script as the owner of
the file, rather than as the user running the web server, so make sure
you really are the same user.

> Probably not permissions. But what?

Well, ultimately, it is permissions. I remember some discussions a
while back on the list about gid possibly not being set correctly by
mod_perl. You might look that up in the archives. You might also try
checking your real and effective uid and gid under CGI and mod_perl.

- Perrin

RE: a require problem

Could it be that during forking a different effective user id is
set, which is what -x checks? are $<, $>, $( and $) all the same
under cgi and mod_perl?

(it sounds like /usr/bin/rcsdiff is not a symbolic link, which
could be treated differently maybe, followsymlinks, etc)

Niels L

> The mod_perl server and the CGI server are the same. It's just a
> handler configured for CGI's for *.cgi and mod_perl for *.pl, and I've
> symlinked from a .pl to the .cgi.
>
> The web server for CGI and mod_perl and the command line run were all
> done as the same user.
>
> Code like this:
>
> warn "$cmd is " . (-x $cmd ? "" : " not") ." EXECUTABLE\n" ;
> warn `ls -l $cmd`;
>
> Yields this under mod_perl:
>
> /usr/bin/rcsdiff is not EXECUTABLE
> -rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
>
> and this from the command line and
>
> /usr/bin/rcsdiff is EXECUTABLE
> -rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
>
> and in a CGI:
>
> /usr/bin/rcsdiff is EXECUTABLE
> -rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
>
> Same server, CGI vs mod_perl, different behavior.
>
> Probably not permissions. But what?
>
> Eric

RE: a require problem

For me, it's the same on both.

What could be the problem here? How can we take the next steps in
debugging this?

ERic=20

> -----Original Message-----
> From: niels=40genomics.dk =5Bmailto:niels=40genomics.dk]
> Sent: Friday, August 29, 2008 3:01 PM
> To: Berg, Eric
> Cc: modperl perl apache org
> Subject: RE: a require problem
>=20
> Could it be that during forking a different effective user id is
> set, which is what -x checks? are =24<, =24>, =24( and =24) all the same
> under cgi and mod_perl?
>=20
> (it sounds like /usr/bin/rcsdiff is not a symbolic link, which
> could be treated differently maybe, followsymlinks, etc)
>=20
> Niels L
>=20
> > The mod_perl server and the CGI server are the same. It's just a
> > handler configured for CGI's for *.cgi and mod_perl for=20
> *.pl, and I've
> > symlinked from a .pl to the .cgi.
> >
> > The web server for CGI and mod_perl and the command line=20
> run were all
> > done as the same user.
> >
> > Code like this:
> >
> > warn "$cmd is =22 . (-x =24cmd ? "" : =22 not=22) .=22 =
EXECUTABLE=5Cn=22 ;
> > warn =60ls -l =24cmd=60;
> >
> > Yields this under mod_perl:
> >
> > /usr/bin/rcsdiff is not EXECUTABLE
> > -rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
> >
> > and this from the command line and
> >
> > /usr/bin/rcsdiff is EXECUTABLE
> > -rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
> >
> > and in a CGI:
> >
> > /usr/bin/rcsdiff is EXECUTABLE
> > -rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
> >
> > Same server, CGI vs mod_perl, different behavior.
> >
> > Probably not permissions. But what?
> >
> > Eric
>=20
>=20
>=20
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - =
- - - - - - -

This message is intended only for the personal and confidential use of the =
designated recipient(s) named above. If you are not the intended =
recipient of this message you are hereby notified that any review, =
dissemination, distribution or copying of this message is strictly =
prohibited. This communication is for information purposes only and =
should not be regarded as an offer to sell or as a solicitation of an =
offer to buy any financial product, an official confirmation of any =
transaction, or as an official statement of Lehman Brothers. Email =
transmission cannot be guaranteed to be secure or error-free. Therefore, =
we do not represent that this information is complete or accurate and it =
should not be relied upon as such. All information is subject to change =
without notice.

--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within =
this communication (including any attachments) is not intended or written =
to be used and cannot be used for the purpose of (i) avoiding U.S. tax =
related penalties or (ii) promoting, marketing or recommending to another =
party any transaction or matter addressed herein.

RE: a require problem

What does 'file $cmd' (the gnu file program) say? is -e true
under mod_perl? I'm out of ideas, but if you are certain its not
due to different Apache configuration, then maybe sifting though
strace output would be worth trying .. and i'm new to mod_perl
anyway. Good luck. My errors are often obvious and found right
in the places where I am not looking.

Niels L

> For me, it's the same on both.
>
> What could be the problem here? How can we take the next steps in
> debugging this?
>
> ERic

Re: a require problem

On Fri, Aug 29, 2008 at 3:43 PM, Berg, Eric wrote:
> For me, it's the same on both.

Nevertheless, there have been problems in the past with GID. Are you
running the latest mod_perl, and perl 5.8.8 or later? See this for
background:
http://marc.info/?l=apache-modperl&m=117922708110568&w=2

- Perrin

RE: a require problem

I'm running this:

Apache/2.2.9 (Unix) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4
Perl/v5.10.0

This is not my biggest problem right now. As you know, I'm still
wrestling with problems associated with Parallel::ForkManager.

I'm going to put together a discrete test of this problem for
demonstration purposes and get back to trying some different versions of
apache, Perl and mod_perl to see if this bug was introduced at some
point along the development path.

Eric

> -----Original Message-----
> From: pharkins=40gmail.com =5Bmailto:pharkins=40gmail.com=5D On=20
> Behalf Of Perrin Harkins
> Sent: Friday, August 29, 2008 4:16 PM
> To: Berg, Eric
> Cc: niels=40genomics.dk; modperl perl apache org
> Subject: Re: a require problem
>=20
> On Fri, Aug 29, 2008 at 3:43 PM, Berg, Eric=20
> wrote:
> > For me, it's the same on both.
>=20
> Nevertheless, there have been problems in the past with GID. Are you
> running the latest mod_perl, and perl 5.8.8 or later? See this for
> background:
> http://marc.info/?l=3Dapache-modperl&m=3D117922708110568&w=3 D2
>=20
> - Perrin
>=20
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - =
- - - - - - -

This message is intended only for the personal and confidential use of the =
designated recipient(s) named above. If you are not the intended =
recipient of this message you are hereby notified that any review, =
dissemination, distribution or copying of this message is strictly =
prohibited. This communication is for information purposes only and =
should not be regarded as an offer to sell or as a solicitation of an =
offer to buy any financial product, an official confirmation of any =
transaction, or as an official statement of Lehman Brothers. Email =
transmission cannot be guaranteed to be secure or error-free. Therefore, =
we do not represent that this information is complete or accurate and it =
should not be relied upon as such. All information is subject to change =
without notice.

--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within =
this communication (including any attachments) is not intended or written =
to be used and cannot be used for the purpose of (i) avoiding U.S. tax =
related penalties or (ii) promoting, marketing or recommending to another =
party any transaction or matter addressed herein.