WampServer

i installed the perl add-on and found it most was not working on the first attempt.

the index.shtml was interpreted as plain text by Mozilla. (MSIE worked)
further it was not the default file for serving to the visitor of this subdir.
renaming it to *.html made it the default and made it work for Mozilla.

copying the printenv.pl from apache2 tree to test.pl
only worked after changing the path to the perl application.

copying the apache1 based test.pl to apache2 subdir worked instantly.

both samples never worked for me when embedding them into
the html page with those &gt--#include statement sequence.

found another solution...

the problem with the *.shtml and mozilla/FF showing plain text
and the problem with the "include" not getting resolved
got fixed trough enabling this two features in the apache config:

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

Q.> i installed the perl add-on and found it most was not working on the first attempt.
A.> wamp does not automatically configure apache to use perl when you install the perl add on. you need to do some configuration yourself to get perl to work:
[forum.wampserver.com]


Q.> the index.shtml was interpreted as plain text by Mozilla.
A.> to get support for shtml, you will need to enable ssi in your httpd.conf file, find this line:
AddType application/x-httpd-php .php3

below it add:
AddType text/html shtml

then find:
#AddHandler send-as-is asis

below that add:
AddHandler server-parsed .shtml

save the file and restart apache for the new setting to take effect.


Q.> further it was not the default file for serving to the visitor of this subdir.
A.> to chose what order you want files to be served using apache's DirectoryIndex directive. the default is:
DirectoryIndex index.php index.php3 index.html index.htm index.html.var

this means when someone goes to [localhsot], apache will look for index.php first, and if it can not find that file, it searches for index.php3. if it can not find that file it searches for index.html and so on. change that that setting in your httpd.conf file to the order that works for you. when you are finished restart apache for the new settings to take effect.


CyberSpatium
WAMP English Forum Admin

okay, i just was not aware of existance of SSI as a term and its interconnection with *.shtml.

it makes me a bit wonder that you suggest a second parameter different to me, but we're both telling it will fix it. (okay, i am still on the learning curve on the specific subject.)

specially for german readers: a few nice try and have fun samples, along with full featured perl CGIs can be found at the self-html website. for SSI the chapter is: [de.selfhtml.org]

(as always... patch the path to perl. cant there be some single(!) override or replacement value for the mentioned in the apache config? until now i have not found such one.)

no you always have to include the path to perl (aka she bang) at the begging of all your perl scripts.


CyberSpatium
WAMP English Forum Admin

The nasty with changing all the pathnames in the scripts
seems to be know. Its adressed by a special key that
apache only knows for the Win32 version:

ScriptInterpreterSource registry

This means the path to the interpreter gets resovled trough registry.
It only changes the situation if your perl interpreter has left its traces there.
To my best understanding the fallback is done using the script contents.

The default value is "script" meaning the apache solely uses the script contents.

see also: [www.usemod.com]

after some initial highs and lows in testing whats doable
i finally found some startup patches to the apache
and this explanation (in german once again):

[buecher.lingoworld.de]

It basically tells that the apache is browsing the registry for *.pl
and then for the default open command in english language
wich perfectly _fails_ for any internationally setup windows.

other sources tell you that its anyway a bad idea browsing
for that key because its user configureable at any time
thus meaning its able breaking your server just because
you want to some _editor_ as the default behafiour for your perl files.
(okay - i have the source, so i could patch that mess to something else...)
More words of that speaker indicated that browsing registry for
script file toolings is more critical than ever expected since even
text files might be able to launch really non desired windows applications.

finally i ended up by adding something like this to my non-english XP install:
HKCR\<your-label-for-perl-scripts>\shell\open\command\(Standard) <full-path-to-your-perl.exe> "%1"

This got tested and confirmed to work for my environment.
I still dont know what sort of behaviour other scripts or text files will trigger.