You are correct, it is not Mod Perl. However, the owner has been told he can run under Mod Perl. Whether he used method 1, 2, 3 or N is his choice.

Running: Three years ago, we could run from back code. Today, not as easy. You learn to live w/in the confines of the current stuff and survive. If you get paid for your time, you are ok. If you get accused of causing the problem, and it is not your problem, you are now not okay. Therein lies the hitch.

So to avoid "guild by association" you keep the business from putting you "at risk".


Cees Hek wrote:
Quoting Dave Van Abel <>:

As to "run like hell from Mod Perl",  I am the one who said it  and will 
defend my statement.

*Mod Perl*:

    Mod Perl is great, and I like to use it, in correct instances.

    However, when the weakly written Perl  - not using strict
    everywhere, getting global values from inside of sub-routines w/o
    passing to it - is subject to Mod Perl, all hell can and will break

If these perl scripts are written as badly as you say they are, then you should
be running from those scripts, instead of mod_perl.  You are making it sound
like mod_perl is to blame, which I think is unfair.

perhaps you should have a look at the Apache::PerlRun module which can be useful
for running 'dirty' perl CGI scripts.

See for more info.

Now if you are talking about running apache using suexec to protect the CGI
scripts from each other, then you have a different problem that mod_perl can't
solve at this moment.  However mod_perl2 which is looking very good at the
moment, but is still not considered suitable for production will solve the
suexec problem as well.  From the mod_perl2 docs:
The perchild MPM is similar to the worker MPM, but is extended with a mechanism
which allows mapping of requests to virtual hosts to a process running under the
user id and group configured for that host. This provides a robust replacement
for the suexec mechanism.



    Implementing Mod Perl on a single server, running two sites, both
    with originally written weak Perl code, can and very likely will
    wreak havic with both sites.

    One site (in SSL) processes Credit Card transactions. This original
    script never used "strict" and has a large number of "included"
    scripts which do not use "strict". Additionally, these same scripts
    are used to connect to MySQL DB.

    Now envision this set of scripts running under Mod Perl.

    Now envision someone doing a credit card transaction, and having the
    CC# field populated with your credit card number (*your Visa Card
    with $50,000 limit* ). Oops, it gets stolen.

    Can this happen? Yes. It happened to my girlfriend last year while
    doing an on-line purchase.

    So, if any of you want to put Mod Perl up on this server, and have
    all hell break loose, _and fix all the problems for free (because
    you maintain the code today and therfore it must be your problem),
    please send me your name, phone number, credit card number and so
    on, so you can have this gig_.

    There, I've backed up my original statement and will say it again,
    "Run like hell if Mod Perl gets installed for this site".


Sam Tregar wrote:

Since this topic is on the list already, here's my response on the topic.


---------- Forwarded message ----------
Date: Thu, 23 Jan 2003 13:45:02 -0500 (EST)
From: Sam Tregar <>
To: Robert <>
Subject: Re: HTML Template versus Template Toolkit

On Thu, 23 Jan 2003, Robert wrote:


Essentially, the argument in favor of using Template Toolkit is that it
is much more powerful

This is true.  But with power comes great responsiblity.  Are your HTML
designers ready for this responsibility?


and provides a more convenient way to pass variables to templates.

This is not true.  HTML::Template provides the simplest API of any
templating module in Perl.


My understanding is that Template Toolkit is 'fat' and may require the
use of mod_perl (or something similar) to speed things up.

It's certainly a larger and slower system than HTML::Template.
HTML::Template is, to my knowledge, the fastest templating system
available for Perl.  And using the (experimental and incomplete)
HTML::Template::JIT add-on, it's even faster than PHP.


Of course, the programmer in favor of using HTML Template says I should
run like hell from using anything like mod_perl.

That's odd.  I use HTML::Template with mod_perl almost exclusively.  The
two are a great combination and HTML::Template includes a caching mode
ideally suited to use with mod_perl.


As the author of HTML Template, I'd appreciate any thoughts or comments
you might have.

The most important issue in choosing between templating systems is your
evaluation of your HTML designers, not your programmers.  HTML::Template
supports a very simple template syntax which is modeled after HTML.  That
means that someone that only knows HTML can learn to create HTML::Template
templates very quickly.  Contrast this to Template Toolkit, where the
template syntax is essentially an entirely new programming language to
learn, and the difference is clear.

Also, HTML::Template enforces the division between coding in Perl and
design in HTML.  The movement of data is entirely one-way, from Perl code
to the template and from there to HTML in the browser.  This means that
the HTML templates can be created and maintained *entirely* separately
>from the Perl code.  Using HTML::Template, a Perl coder does what he does
best, code in Perl, and your HTML designers do what they do best, design
in HTML.

All that aside, though, I don't want to leave you with the impression that
I think the Template Toolkit is no good.  It's actually a very well
designed system which just happens to meet different goals than the ones I
set for HTML::Template.  If you do end up using it you'll still be miles
ahead of the poor fools using JSP!


This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
Html-template-users mailing list


Dave Van Abel
Colorado, USA
Yahoo Instant Messenger = dave_vanabel


This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
Html-template-users mailing list


Dave Van Abel
Colorado, USA
Yahoo Instant Messenger = dave_vanabel