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.

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).

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?

Someone posts to SOPW "How do I do blah" 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.

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?

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

make Makefile.PL LIB=~/lib
[download]

and all your troubles will be over!"

What if there is a situation where one or more of the following is an issue:

• 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
• 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.
• 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.

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. 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 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.

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.