LesleyB has asked for the wisdom of the Perl Monks concerning the following question:

Greetings, oh wise ones

I am completely befuddled and am seeking your wise advice. I have separated my befuddlement into separate headings as much as I can.

TT2 and CGI

I started using FB as suggested by oko1 here . I felt encouraged by the ability to use TT2 because I already had some work in that format.

I reworked through the second chapter of ye Badger Book and then reworked the actual site in question making a simple set of templates that worked with static pages and ttree.

Then came the setting up of the CGI side of things. Temporarily I moved the templates aand source files into the cgi directory for this work in progress on my local machine, figuring I could deal with the proper layout of the templates and the cgi later on. First sloppy thing.

Now I have a common head element that mostly uses site constant data, the title and keywords might change for a page but stylesheet, javascript file and other headers don't hugely change.

<title>[% sitename %]::[% title %]</title> <base href="[% baseurl%]" /> <meta name="Author" content="[% author %]" /> <meta name="robots" content="[% robot %]" /> <meta http-equiv="expires" content="now" /> <meta http-equiv="pragma" content="no-cache" /> <meta name="keywords" content="[% keywds %]" /> <link rel="stylesheet" href="[% style %]" type="text/css" /> <script src="[% script %]" type="text/javascript"></script> <link rel="shortcut icon" href="[% icon %]" /> </head> <body id="[% pagename %]"> <div id="container">

Using ttree for static page construction, I can pre-process a configs file which simply processes a file called site declaring the fixed data.

Under cgi, I lost this preprocessing capability and I am wondering how to get it back.

I tried [%- INCLUDE site -%] but this didn't seem to load the site data. I tried [%- PROCESS site -%] but that didn't work either, so I ended up simply adding the constant data as declarations in the template which something I am deeply unhappy about. I would prefer constant site data to be separate so that it can be easily maintained.

Working on Email::Valid

So far so good...Then I tried Email::Valid. For such a simple module I managed to spend a lot of time on this but I eventually got what I wanted with this snippet

my $emv = Email::Valid->new(); $emv->tldcheck(1); $emv->mxcheck(1); $addr = $emv->address(-address => $addr) if $addr;

I couldn't figure out how to set tldcheck and mxcheck successfully within one call to Email::Valid->address. If there is a way would someone let me know?

An installation problem

I discovered that I had the default Debian version of FB in it's usual place of /usr/share/perl5/ This is version 3.03.

However, I was playing around with CPAN some time ago and have ended up with version 3.0501 in

/usr/local/share/perl/5.8.8/CGI
Similar things happen for Email::Valid. On my local machine, I am using the later versions.

I really need rewind my mistakes with CPAN on my local machine and get back to the default install of perl. This is all on Debian stable machines - except the bits I may have made unstable by playing with CPAN on my local machine .

Ideally I would like then to be able to install and use up to date elements of perl, For example, CGI v3.05 is the default installed on Debian atbel and I'd prefer to use CGI v3.38 if for nothing else but to clear an annoying charset bug. How can I safely do this?

I would like to avoid having to re-install Debian stable to completely rewind my local machine to a safe state. I would prefer to simply remove the perl component and then re-install it. Is this possible?

I did see a document out there that described how to set up a dual perl isntallation without threatening the distribution on which it works but I didn't bookmark the page. Mea culpa. If anyone can point me in the right direction on this it would help me tremendously

Having achieved these aims what would I need to consider if I then change over to mod_perl on Apache v2.x?

Replies are listed 'Best First'.
Re: TT2 and FB between two different installations
by jethro (Monsignor) on Jul 21, 2008 at 15:36 UTC
    One big problem you seem to have is that you have a server with some older versions of perl-modules. Is that a server under your control, i.e. can you update the machine or at least install new versions of the modules?

    If yes, then that is the first thing you should do. If no, then there is no real advantage in installing CGI 3.38 on your local machine.

    If you want to get rid of modules you installed into /usr/local/share/perl/, you might just delete them and adjust perllocal.pod (see http://www.cpan.org/misc/cpan-faq.html#How_installed_modules). But I haven't tested this method and can't guarantee its correctness. The absence of the question 'How can I delete a perl module installed by cpan' in the CPAN FAQ might be a warning sign ;-).

      Tankyou for your reply

      I do have control of the remote machine and could upgrade. This would then be outside the standard installation on the remote machine.

      I did load CPAN modules on my local machine, to get the latest versions of some stuff but this became a problem when a system upgrade occurred. The system didn't like the Errno.pm file in /usr/local/share/perl/5.8.8 and refused to install a cpio upgrade.

      I am wary of having the same problem on my remote machine.

        Isn't Errno.pm a core module? Then why do you have it in /usr/local/share?

        The only reason to account for that situation that I can think of is that you installed a new perl version in /usr/local and the system is using this new perl now.

        In that case it might help to rename the newer perl to perl5.8.8 (or delete it, since it probably is an alias to perl5.8.8 anyway). Let the system use and update its old perl. In your homedirs ~/bin you can put an alias to perl5.8.8. Provided that your home bin is first in your PATH your non-root scripts will then use the newer perl.

        IMPORTANT: The only script that you must call as root with perl5.8.8 instead of the system perl is cpan (if you want the perl modules in /usr/local and not in your homedir). You might even patch the cpan script with 'use 5.8.8' so that you don't forget it.

        This should probably also help your cpio upgrade getting through.

        This is also the method I would employ on your remote machine. Install a newer perl in /usr/local and make sure through renaming that root and the system doesn't use it. Let the system care for the system perl, only your web scripts (in other words the web server) and the cpan script should use the newer perl.

Re: TT2 and FB between two different installations
by LesleyB (Friar) on Jul 22, 2008 at 11:44 UTC

    The post originally contained stuff about FB, TT2 and the stumbit button.

    I am a brain dead moron on (at least) two counts

    1. I deleted from the original post instead of working out how to put a line through the text I wanted to delete.
    2. I didn't look at the tutorials available to work out how to use a stumbit button without FB::Field::submit.pm

    My apologies