|Syntactic Confectionery Delight
Thoughts on script portabilityby blue_cowdawg (Monsignor)
|on Jan 24, 2004 at 22:55 UTC
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
and all your troubles will be over!"
What if there is a situation where one or more of the following is an issue:
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.