Andy,
This is an extract from a virtual server within my srm.conf, you'll need
mod_perl for this to work though.
mod_perl seems to link perl into apache, it allows tight integration with
the apache api, lets you run perl scripts and build perl modules. The
mod_perl.conf contains a line "PerlModule Apache::Registry" this loads the
module that will handle perl scripts in the dir as below. without mod_perl I
don't think apache would know what to do with directives like PerlModule.
Alias /cgi-bin/ "/web/user/cgi-bin/"
<Location /cgi-bin>
SetHandler perl-script
PerlHandler Apache::Registry #<- This tells apache to use the module
Apache::Registry on files in here
Options ExecCGI
Allow from all
PerlSendHeader On
</Location>
There's an awful lot in mod_perl and it has some great performance features,
I've attached my personal list of gotcha's for mod_perl, it's all on the web
in the documentation but this could save you some time.
If this is all too much then I'd stick with wrapping perl in .com files as
previously mentioned. If you look in the perl_root dir there are some
examples of .coms that wrap perl. It won't be as efficient but it could save
you some time.
Regards,
Martin.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 27 November 2002 09:25
To: [EMAIL PROTECTED]
Subject: RE: Apache won't run perl scripts
Martin
There's no urgency on this so whenever you've got the time.
Yes I am in the UK.
Andy
Internet
[EMAIL PROTECTED] - 27/11/2002 06:49
To: Andy PARKER
cc:
Subject: RE: Apache won't run perl scripts
Hi Andy,
No prob, I'm a little tied up today but I should be able to get some more
info to you tomorrow, are you in the UK?
Martin.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 26 November 2002 11:36
To: [EMAIL PROTECTED]
Subject: RE: Apache won't run perl scripts
Martin
Thanks for replying. I'd appreciate an extract of a config file just to see
if there's some value I've missed.
Thanks Andy
Internet
[EMAIL PROTECTED] - 25/11/2002 19:33
To: Andy PARKER, vmsperl
cc:
Subject: RE: Apache won't run perl scripts
Have you installed mod_perl?, I'm not saying you can't run scripts without
it but I've had no problems with, perl 5.6.1 vms 7.3 apache 1.3.20 and the
supported version of mod perl. When you install mod_perl it adds directives
to some of the conf files that you need. There's may be an easier way but
maybe this will help. I could also mail you extracts of an apache config
file if that would help.
Martin.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 25 November 2002 13:56
To: [EMAIL PROTECTED]
Subject: Apache won't run perl scripts
I've installed Apache 1.3.20 on an Alpha running VMS 7.3-1 and am trying to
use perl v5.6.
Perl is installed fine and runs without problem from the command line.
However, when I try and run a perl cgi script using the browser I get
"Internal Server Error".
The problem seems to be that Apache want's to run everything as a DCL
command file as when I look in ERROR_LOG I see the warning
"malformed header from script. Bad header=%DCL-W-NOCOMD, no command on l:
".
Can someone please tell me how I get round this.
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
Some Perl Gotcha's
Using modules with mod_perl and Apache
mod_perl has a neat trick, it caches compiled code in the Apache server/processes for
enhanced performance,
this is great but there are a couple of things to note.
The code is only run once, the compiled version is then copied to memory, the only
drawback I can see to this is that it's
not so great for memory usage.
mod_perl will reload/compile the script if the modification date of the script
changes,
however because modules are pulled in at compile time changes to them won't be picked
up.
This means that until you have modfied the script that uses the module or you restart
Apache, module changes will not be reflected. This applies for libraries called using
require and use.
You can turn this feature off by using Apache::PerlRun in your mod_perl.conf instead
of Apache::Registry.
This will make it behave as it would with any other CGI(no cache).
Using BEGIN with mod_perl and Apache
BEGIN with mod_perl also executes code at compile time, However, since mod_perl
normally only compiles scripts and modules once, in the parent server or once
per-child,
BEGIN blocks in that code will only be run once. Once a BEGIN has run, it is
immediately undefined.
In the mod_perl environment, this means BEGIN blocks will not be run during each
incoming request
unless that request happens to be one that is compiling the code.
This can be interesting if your modifying @INC.
