Re: Current directory
One way is to configure the CPAN module: C:\ perl -MCPAN -e shell which, the first time you invoke it, will lead you through a dialogue. You can accept most of the defaults, except for the list of CPAN mirrors to use. Then, at the CPAN.pm shell prompt, you can say cpan install CGI Thanks for answering Randy, but I got a working PPM module of CGI for HP-UX and modified the module's description files to make PPM think it's for Win32. Since it's just Perl code, and not XS, should work. If anyone wants this PPM, I can make it available. Though it would be more useful on a known repository. But I still get the same message... [Mon Aug 04 09:31:57 2003] [error] Global $r object is not available. Set: PerlOptions +GlobalRequest in httpd.conf at D:/Perl/lib/CGI.pm line 307. Compilation failed in require at D:/htdocs/_startup.pl line 33. Is there anything else I can check other than the CGI.pm version?
Re: Current directory
BTW, perl -MCGI -e print $CGI::VERSION; 2.98 J-S - Original Message - From: Jean-Sebastien Guay [EMAIL PROTECTED] To: Randy Kobes [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 04, 2003 9:32 AM Subject: Re: Current directory One way is to configure the CPAN module: C:\ perl -MCPAN -e shell which, the first time you invoke it, will lead you through a dialogue. You can accept most of the defaults, except for the list of CPAN mirrors to use. Then, at the CPAN.pm shell prompt, you can say cpan install CGI Thanks for answering Randy, but I got a working PPM module of CGI for HP-UX and modified the module's description files to make PPM think it's for Win32. Since it's just Perl code, and not XS, should work. If anyone wants this PPM, I can make it available. Though it would be more useful on a known repository. But I still get the same message... [Mon Aug 04 09:31:57 2003] [error] Global $r object is not available. Set: PerlOptions +GlobalRequest in httpd.conf at D:/Perl/lib/CGI.pm line 307. Compilation failed in require at D:/htdocs/_startup.pl line 33. Is there anything else I can check other than the CGI.pm version?
Re: Current directory
On Mon, 2003-08-04 at 09:32, Jean-Sebastien Guay wrote: But I still get the same message... [Mon Aug 04 09:31:57 2003] [error] Global $r object is not available. Set: PerlOptions +GlobalRequest in httpd.conf at D:/Perl/lib/CGI.pm line 307. Compilation failed in require at D:/htdocs/_startup.pl line 33. Is there anything else I can check other than the CGI.pm version? First, check your conf file to be sure you have this turned on. There are docs related to it here: http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_ You can test it by writing a little handler (or Registry script) that calls Apache-request(). That should return an Apache::RequestRec object if all is well. If it doesn't, you may have an old mod_perl 2 build or you may have found a bug. If you can't get that to work, there is also the direct approach which is to pass a RequestRec object to CGI.pm when you call the new() method. Registry scripts get a RequestRec object passed to them as their first param, so you can just shift it into a variable (usually called $r) and pass it as CGI-new($r). - Perrin
Re: Current directory
Perrin, First, check your conf file to be sure you have this turned on. There are docs related to it here: http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_ The docs also state that unless it's explicitly turned _off_, it's on by default. But I turned it on anyways before I sent my last message. Here's the relevant section of my httpd.conf: begin LoadModule perl_module modules/mod_perl.soLoadFile "D:/Perl/bin/perl58.dll" PerlModule Apache2PerlSetEnv SCRIPT_ROOT "D:/htdocs"PerlRequire "D:/htdocs/_startup.pl" Files ~ "\.cgi$" SetHandler perl-script PerlResponseHandler ModPerl::Registry Options +ExecCGI PerlOptions +ParseHeaders +GlobalRequest /Files end And here's my _startup.pl script: begin #---# Default module inclusions as per the Apache# mod_perl installation instructionsuse Apache2 ();use ModPerl::Util ();use Apache::RequestRec ();use Apache::RequestIO ();use Apache::RequestUtil ();use Apache::Server ();use Apache::ServerUtil ();use Apache::Connection ();use Apache::Log ();use Apache::Const -compile = ':common';use APR::Const -compile = ':common';use APR::Table ();use Apache::compat ();use ModPerl::Registry ();use CGI (); #---# General modulesuse Time::localtime;use Data::Dumper;use Date::Calc qw(:all); #---# Hybride modules # Add the top-level directory for the modules into the module search path.use lib qw(D:/htdocs); # ... ... The modules I want to pre-load are currently all commented out, until # ... ... I get a running server to test them one at a time... end You can test it by writing a little handler (or Registry script) that calls Apache-request(). That should return an Apache::RequestRec object if all is well. If it doesn't, you may have an old mod_perl 2 build or you may have found a bug. If you can't get that to work, there is also the direct approach which is to pass a RequestRec object to CGI.pm when you call the new() method. Registry scripts get a RequestRec object passed to them as their first param, so you can just shift it into a variable (usually called $r) and pass it as CGI-new($r). Doesn't all this require that I actually get a running Apache server first? The error message shows up when I try to start up the Apache service! As I understand it, the _startup.pl script tries to require() CGI.pm, which gives the error message. So I never get a running Apache instance to run any scripts in. If there's anything else I can try, or if you see anything in the above config files, please let me know. Thanks for your patience on this... J-S ___Jean-Sébastien Guay [EMAIL PROTECTED]Software Developer, Hybride http://www.hybride.comPiedmont, Québec, Canada
Re: Current directory
On Mon, 2003-08-04 at 12:08, Jean-Sebastien Guay wrote: Doesn't all this require that I actually get a running Apache server first? The error message shows up when I try to start up the Apache service! What? That shouldn't happen unless something is calling CGI-new in your startup, which is a bad thing to do. Maybe some script you're loading is doing that. Try to figure out what's doing it. As I understand it, the _startup.pl script tries to require() CGI.pm, which gives the error message. What happens if you comment out CGI.pm from your startup.pl? - Perrin
Re: Current directory
On Mon, 2003-08-04 at 12:08, Jean-Sebastien Guay wrote: Doesn't all this require that I actually get a running Apache server first? The error message shows up when I try to start up the Apache service! What? That shouldn't happen unless something is calling CGI-new in your startup, which is a bad thing to do. Maybe some script you're loading is doing that. Try to figure out what's doing it. You're absolutely right... Shame on me. The first homegrown module I was importing did exactly that. It would try to get the user cookie right on use(), which of course isn't very good practice. So I've modified it to get it on first call of a certain method, and to return that same value on subsequent calls. Geez... Now I have to transition all my scripts and other modules to mod_perl. Where could I find examples of real-life conversion between normal CGI and mod_perl? (Other than the perl.apache.org docs, which even though they're great, lack real examples of what needs to be done for the really ugly types of code...) Thanks for bearing with me through this... J-S ___ Jean-Sébastien Guay [EMAIL PROTECTED] Software Developer, Hybride http://www.hybride.com Piedmont, Québec, Canada
Current directory
Hello again, I have another problem trying to get one of my Perl modules to load in my startup.pl script for the first time. In a couple places in my scripts, I assume that the current directory is the one in which the current script is being run. So for example, if my DocumentRoot is D:/htdocs/ and someone requests http://myhostname/script.cgi, if I need touse some files, my current directory is D:/htdocs. The two things I currently do this for are a) configuration file, which is loaded on startup by the module I am trying to get loaded in my startup.pl script b) templates (for template-toolkit), which I specify to be in the directory 'templates' relative to the location where the scripts are running, meaning they are in D:/htdocs/templates. I see only disadvantages to having to specify absolute paths in both these cases. For one, I have another web server running on port 8080, which I use to test my scripts on, and whose DocumentRoot is D:/htdocs-dev. So if I had to manually change the paths each time I copied files over from the development DocumentRoot to the production one, I would go crazy. Is there a way to guarantee that the current directory will be the correct one when I need it to? Or does anyone have another suggestion? Thanks! J-S ___Jean-Sébastien Guay [EMAIL PROTECTED]Software Developer, Hybride http://www.hybride.comPiedmont, Québec, Canada
Re: Current directory
On Fri, 2003-08-01 at 15:46, Jean-Sebastien Guay wrote: I see only disadvantages to having to specify absolute paths in both these cases. For one, I have another web server running on port 8080, which I use to test my scripts on, and whose DocumentRoot is D:/htdocs-dev. So if I had to manually change the paths each time I copied files over from the development DocumentRoot to the production one, I would go crazy. There are dozens of possible answers to this. I typically put things relative to the web server root, which is described here: http://perl.apache.org/docs/1.0/api/Apache.html#Apache_E_gt_server_root_relativerelative_path___ Another approach would be to look up the directory that your script is in and either chdir to that or pass it to your modules and have them use it. There are also common approaches like passing some kind of application root either in an environment variable or in httpd.conf with a PerlSetVar. - Perrin
Re: Current directory
Hi Perrin,
Thanks for both your answers. Indeed, for the other question, I was using
CGI 2.91 instead of 2.93 (because that one isn't yet available for Perl 5.8
via PPM). I'll find a way to upgrade it.
There are dozens of possible answers to this.
...
There are also common approaches like passing some kind of application
root either in an environment variable or in httpd.conf with a
PerlSetVar.
Unfortunately, this doesn't seem to work. Even if I put the PerlSetVar
statement before my PerlRequire statement like so:
PerlSetVar SCRIPT_ROOT D:/htdocs
PerlRequire D:/htdocs/_startup.pl
the module, which is then loaded from _startup.pl, sees only undef when I
try to print $ENV{SCRIPT_ROOT}; ... I also tried to do this right before
use()ing my module:
$ENV{SCRIPT_ROOT} = 'D:/htdocs';
and it gives the same result. Could the problem come from the fact that
_startup.pl is trying to load the module before Apache is actually finished
loading, so the environment is not in a valid state at that point? What else
could cause this?
Thanks,
J-S
___
Jean-Sébastien Guay [EMAIL PROTECTED]
Software Developer, Hybride http://www.hybride.com
Piedmont, Québec, Canada
Re: Current directory
On Fri, 2003-08-01 at 16:59, Jean-Sebastien Guay wrote:
Unfortunately, this doesn't seem to work. Even if I put the PerlSetVar
statement before my PerlRequire statement like so:
PerlSetVar SCRIPT_ROOT D:/htdocs
PerlRequire D:/htdocs/_startup.pl
the module, which is then loaded from _startup.pl, sees only undef when I
try to print $ENV{SCRIPT_ROOT};
You're thinking of PerlSetEnv. PerlSetVar values are retrieved
differently. Take a look at this:
http://perl.apache.org/docs/1.0/guide/config.html#PerlSetEnv_and_PerlPassEnv
Note that you can also just do this:
Perl
$MyConfig::SCRIPT_ROOT = 'foo';
/Perl
And then in your module:
my $root = $MyConfig::SCRIPT_ROOT;
- Perrin
Re: Current directory
On Fri, 1 Aug 2003, Jean-Sebastien Guay wrote: Hi Perrin, Thanks for both your answers. Indeed, for the other question, I was using CGI 2.91 instead of 2.93 (because that one isn't yet available for Perl 5.8 via PPM). I'll find a way to upgrade it. One way is to configure the CPAN module: C:\ perl -MCPAN -e shell which, the first time you invoke it, will lead you through a dialogue. You can accept most of the defaults, except for the list of CPAN mirrors to use. Then, at the CPAN.pm shell prompt, you can say cpan install CGI Before doing this, you'll need Microsoft's nmake utility; a link on where to get it appears in the Win32 configuration page at http://perl.apache.org/. best regards, randy
Re: Current directory
Hi!
On Tue, Jun 17, 2003 at 02:19:49AM +0200, Oskar wrote:
when I am executing perl script on Apache it seems that the current
directory is not the directory where the script is located but the directory
c:\program files\apache group\apache. I need current dir to be the script
dir since i have some pm in the script directories.
I have apache 1.3.27 and mod_perl 1.
See:
http://perl.apache.org/docs/1.0/guide/porting.html#_INC_and_mod_perl
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Current directory
I already read that article before posted the message here but it does not
solve the problem: I am running more than one web so the adding of each
particular directory seems to me little bit dumb. Also i dont see the reason
why the current dir should be changed to the dir different from the script
dir.
Any other suggestion to solve it?
Oskar
- Original Message -
From: Thomas Klausner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 17, 2003 9:41 AM
Subject: Re: Current directory
Hi!
On Tue, Jun 17, 2003 at 02:19:49AM +0200, Oskar wrote:
when I am executing perl script on Apache it seems that the current
directory is not the directory where the script is located but the
directory
c:\program files\apache group\apache. I need current dir to be the
script
dir since i have some pm in the script directories.
I have apache 1.3.27 and mod_perl 1.
See:
http://perl.apache.org/docs/1.0/guide/porting.html#_INC_and_mod_perl
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Current directory
On Tue, 17 Jun 2003, Oskar wrote:
- Original Message -
From: Thomas Klausner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 17, 2003 9:41 AM
Subject: Re: Current directory
Hi!
On Tue, Jun 17, 2003 at 02:19:49AM +0200, Oskar wrote:
when I am executing perl script on Apache it seems that the
current directory is not the directory where the script is
located but the directory c:\program files\apache
group\apache. I need current dir to be the script dir since
i have some pm in the script directories. I have apache
1.3.27 and mod_perl 1.
See:
http://perl.apache.org/docs/1.0/guide/porting.html#_INC_and_mod_perl
I already read that article before posted the message here but
it does not solve the problem: I am running more than one web
so the adding of each particular directory seems to me little
bit dumb. Also i dont see the reason why the current dir should
be changed to the dir different from the script dir. Any other
suggestion to solve it?
You might try the FindBin module; from the docs,
NAME
FindBin - Locate directory of original perl script
SYNOPSIS
use FindBin;
use lib $FindBin::Bin/../lib;
or
use FindBin qw($Bin);
use lib $Bin/../lib;
However, note the following:
KNOWN ISSUES
If there are two modules using FindBin from different
directories under the same interpreter, this won't work. Since
FindBin uses BEGIN block, it'll be executed only once, and
only the first caller will get it right. This is a problem under
mod_perl and other persistent Perl environments, where you
shouldn't use this module. Which also means that you should avoid
using FindBin in modules that you plan to put on CPAN. The only
way to make sure that FindBin will work is to force the BEGIN
block to be executed again:
delete $INC{'FindBin.pm'};
require FindBin;
--
best regards,
randy kobes
Current directory
Hi, when I am executing perl scripton Apache it seems that the current directory is not the directory where the script is locatedbut the directory c:\program files\apache group\apache. I need current dir to be the script dir since i have some pm in the script directories. I have apache 1.3.27 and mod_perl 1. Thanks Oskar
Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)
At 06:22 PM 1/28/2003, Stas Bekman wrote: [...] Is it true what was said in one of the other threads -with mod_perl (Apache 1.3.27) the current working directory is different from the dir where the script lies? [...] As I've followed up (because I knew that that particular post will create confusion), it *is* the script's dir for mod_perl 1.x. (Apache::Registry and friends) Ok Tks I guess I should have read the thread carefully. It's *currently* not the case with mod_perl 2.0 (ModPerl::Registry and friends), but this should change to be the same as 1.x by the time 2.0 is released. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)
Actually I haven't got this to work. I'm yet trying to figure how to load the module (PerlModule Apache::SSI) in the .htaccess with it actuall residing in the /perl/ directory rather than the standard lib directories. Why? It's a module, not a CGI script. I'm not sure whether the company that's hosting my web site will want to install any non-critical module (They ahve done me a favor allowing me to run mod_perl ... ) So I want to see if I have any options installing it under my directory tree. If you don't want to put it in your standard @INC paths, you can put it under APACHE_HOME/lib/perl/ which is automatically added to @INC by mod_perl. - Perrin
Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)
[EMAIL PROTECTED] wrote: I'm not sure whether the company that's hosting my web site will want to install any non-critical module (They ahve done me a favor allowing me to run mod_perl ... ) So I want to see if I have any options installing it under my directory tree. Okay. You need to modify @INC then. Take a look here for examples: http://perl.apache.org/docs/1.0/guide/config.html#The_Startup_File - Perrin
Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)
At 10:50 AM 1/29/2003, Perrin Harkins wrote: [EMAIL PROTECTED] wrote: I'm not sure whether the company that's hosting my web site will want to install any non-critical module (They ahve done me a favor allowing me to run mod_perl ... ) So I want to see if I have any options installing it under my directory tree. Okay. You need to modify @INC then. Take a look here for examples: http://perl.apache.org/docs/1.0/guide/config.html#The_Startup_File Tks. Dr
mod_perl and current directory (was Re: Newbie Q on Apache::Include)
You can do this. Technically I think you can POST to a file, but you
don't need to.
You can do this lots of ways, including post-processing the output of a
CGI script with a module like CGI::SSI. What I
Tks that way worked except for the #config sizefmt of mod_include
would suggest is writing a script that you will run under
Apache::Registry, and calling Apache::Include-virtual('/uri/of/file') to
do the includes.
From the documentation of the Apache::Include I couldn't make out whether
it handled other features like set which I am using. But your siggestion
led me to search on CPAN and found Apache::SSI. That was reasonably
well-documented and I was planning on using it except the module couldn't
be found. Is it true what was said in one of the other threads -with
mod_perl (Apache 1.3.27) the current working directory is different from
the dir where the script lies? If so how does one use code organized uder
one's own directory? (Need to know this as my host does not want to install
modules for me.)
Rgds
Dr
Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)
[...] Is it true what was said in one of the other threads -with mod_perl (Apache 1.3.27) the current working directory is different from the dir where the script lies? [...] As I've followed up (because I knew that that particular post will create confusion), it *is* the script's dir for mod_perl 1.x. (Apache::Registry and friends) It's *currently* not the case with mod_perl 2.0 (ModPerl::Registry and friends), but this should change to be the same as 1.x by the time 2.0 is released. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)
[EMAIL PROTECTED] wrote: Tks that way worked except for the #config sizefmt of mod_include That should work fine. What's broken with it? From the documentation of the Apache::Include I couldn't make out whether it handled other features like set which I am using. It does not implement SSI, it just integrates an extra tag (#perl) into mod_include. Everything that works in your current mod_include pages should continue to work. But your siggestion led me to search on CPAN and found Apache::SSI. Apache::SSI is good too. It will use more RAM, but it is slightly faster than mod_include. - Perrin
Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)
At 06:54 PM 1/28/2003, Perrin Harkins wrote: [EMAIL PROTECTED] wrote: Tks that way worked except for the #config sizefmt of mod_include That should work fine. What's broken with it? (Frankly I'm so eagar to not just get my feet wet in mod_perl (just started on it today), but drown in it I didn't follow up on this prob.) !--#config sizefmt=Mb -- works with mod_include Got a [an error occurred while processing this directive] (well actually the errmsg that I had set) with CGI::SSI. As I said I didn't really follow-up to see if this is a prob. From the documentation of the Apache::Include I couldn't make out whether it handled other features like set which I am using. It does not implement SSI, it just integrates an extra tag (#perl) into mod_include. Everything that works in your current mod_include pages should continue to work. Oh kinda like embedding perl code in an shtml? But your siggestion led me to search on CPAN and found Apache::SSI. Apache::SSI is good too. It will use more RAM, but it is slightly faster than mod_include. Actually I haven't got this to work. I'm yet trying to figure how to load the module (PerlModule Apache::SSI) in the .htaccess with it actuall residing in the /perl/ directory rather than the standard lib directories. Tks Dr
Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)
[EMAIL PROTECTED] wrote: !--#config sizefmt=Mb -- works with mod_include Got a [an error occurred while processing this directive] (well actually the errmsg that I had set) with CGI::SSI. As I said I didn't really follow-up to see if this is a prob. Oh, sorry, I missed the part about CGI::SSI. That will work with mod_include (and thus with Apache::Include). It does not implement SSI, it just integrates an extra tag (#perl) into mod_include. Everything that works in your current mod_include pages should continue to work. Oh kinda like embedding perl code in an shtml? It lets you run any Perl subroutine in the middle of a page. It also lets you include files (a virtual include) from within a Perl script by calling the Apache::Include module. Actually I haven't got this to work. I'm yet trying to figure how to load the module (PerlModule Apache::SSI) in the .htaccess with it actuall residing in the /perl/ directory rather than the standard lib directories. Why? It's a module, not a CGI script. If you don't want to put it in your standard @INC paths, you can put it under APACHE_HOME/lib/perl/ which is automatically added to @INC by mod_perl. - Perrin
