perlmeditation
blue_cowdawg
<p>
I've been tooling around PM now since 2001. Before
that I've been using Perl since the dawn of Perl when it
was being shipped around USENET as shar files.
</p>
<p>
One of the things that always attracted me to Perl was the
fact that when I wrote a script on HPUX on a RISC system
for instance there
was a pretty darn good chance if I was careful that I could
run it say on AT&T System V Release 3 on a 3B2 with
very minor changes (paths to files and such).
</p>
<p>
Enterh the godsend that CPAN modules are. Modules in
general for that matter. A really nifty way to write
something once and just ship it to whereever you need it.
Additionally you had the ability to not re-invent the
wheel if someone else already wrote a module to do what
you needed done. Why write when you can borrow?
</p>
<p>Someone posts to SOPW "How do I do <i>blah</i>"
and most of us tell the OP "look into the module
FOO::Lite! Don't reinvent the wheel!" I know this
because I am guilty as charged myself.
</p>
<p>
But! There is a rub. This is a situation that I have
run into many times. What if a) the module your well
crafted script depends on a module that does not
exist on the target environment
and b) you have no way to install the module?
</p>
<p>
I can hear the ready answer Monks have to that already:
"But you can always install a CPAN module on a
machine in your local environment! Do a
<code>
make Makefile.PL LIB=~/lib
</code>
and all your troubles will be over!"
</p>
<p>
What if there is a situation where one or more
of the following
is an issue:
<ul>
<li>You don't have shell access to the target machine?
I have developed code for clients where this was the case
and have had to do some fancy footwork to solve the
problem
</li>
<li>You lack compiler tools for the target machine?
Case in point: I was developing code for the client I
just intimated to above and his target machine was
a Win2K box. I run strictly Linux on my development system
and do not have access to Microsoft compilers.
</li>
<li>Uncooperative hosting facility. I'm spoiled, the
folks that host my web site are very responsive to my
requests for CPAN module installations. This same client
I have been referencing without mentioning their name
had a hosting facility that was the polar opposite of that
spirit. It happens.
</li>
</ul>
</p>
<p>Some modules are pure Perl so if a monk decides to
"build"
them on their own machine at home they can FTP the results
to the target machine in a manner where the script in
question can "find" them for instance in the
cgi-bin directory. Where this works, do it.
[cpan://Net::CMD] is one such example of where I had to
copy it from my Perl installation and upload it to the
hosting site. Hey... it worked. That was so I could then
get [cpan://Net::SMTP] to work so the application I was
writing could send email. The hosting site provided no
other mechanism for Perl to be able to do that. Their
suggestion was to use .ASP instead of Perl.
</p>
<p>
I said all that to say this: the phrase TIMTOWTDI applies
even to the simple pleasures of module use. And another
thing: on rare occasion you really do have to re-invent
the wheel.
</p>
<div class="pmsig"><div class="pmsig-72516">
<hr>
<table align="center" class="signature-main" width="400" cellpadding="0" cellspacing="0">
<tr><td class="signature-topbar" colspan="2" align="center" bgcolor="#1BA6A4">Peter L. Berghold -- Unix Professional<br>Peter at Berghold dot Net</td></tr>
<tr class="signature-passion"><td align="right" > </td>
<td align="justify" > Dog trainer, dog agility exhibitor, brewer of
fine Belgian style ales. Happiness is a warm, tired, contented dog curled up at your side and
a good Belgian ale in your chalice.</td></tr>
</table>
</div></div>