Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Thoughts on script portability

by blue_cowdawg (Prior)
on Jan 24, 2004 at 22:55 UTC ( #323886=perlmeditation: print w/ replies, xml ) Need Help??

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


Peter L. Berghold -- Unix Professional
Peter at Berghold dot Net
   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.

Comment on Thoughts on script portability
Download Code
Re: Thoughts on script portability
by Vautrin (Hermit) on Jan 24, 2004 at 23:21 UTC
    # 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

    As you have always mentioned you can BEGIN { unshift @INC, "/path/to/Modules"; } on all your scripts and create your own modules directory. If you are talking about modules that need to be compiled you can always cross compile on your machine (statically link the libraries!!!!!!!) and upload them. This can be a royal PITA though. Also remember that running shell escapes (i.e. system and `s) are not always verboten on machines like they should. You can use this to give yourself pseudo-shell access.

    Your other points, i.e. making it impossible to figure out enough information from the server or not having compilation tools can make it impossible to install your own modules pretty much means you have to take a hike. Vote with your feet and go somewhere else. Any client who wants a perl solution should usually be more then willing to make a perl solution feasible. If they make it impossible (which is possible) you pretty much have to walk.

          you can BEGIN { unshift @INC, "/path/to/Modules"; } on all your scripts

      Actually had a case where that didn't work either. The hosting site had set the CGI environment in such a way that it could not see outside of a very limited environment similar to a chroot environment in Unix. Other than d:\path\perl or e:\cgi-bin was invisible.


      Peter L. Berghold -- Unix Professional
      Peter at Berghold dot Net
         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.

        Even if you are jailed (chrooted) into the CGI directory you should still be able to create a directory (even over FTP -- unless the servers are so locked down that you can't even upload files ;-D), and then use "./modules" (or whatever) as the path to the modules. Of course, that's on a Windows, server, correct? Hmmmm. I suppose worst case scenario you could just keep all the modules in the current directory.

Re: Thoughts on script portability
by perrin (Chancellor) on Jan 25, 2004 at 00:23 UTC
    If you don't have a shell, remember: CGI is code. You can run anything in a CGI script, including commands to install modules. People have actually written (very dangerous) fake shells through a CGI form interface. In general though, I would advise you to stay far away from hosting environments that are that lame. An account with shell access and CGI is worth the small amount it costs.

          I would advise you to stay far away from hosting environments that are that lame.
      I certainly agree with that sentiment! Unfortunately as a consultant you don't always get to specifiy the environment. In a reply elsewhere in this thread someone said I should be happy to be rid of the client. There's more truth to that then I want to get in to here!

      I bring up this extreeme case mainly as a lesson that demonstrates the addage "keep an open mind". Lots of Monks (including myself) become spoiled by having environments that let them do whatever they want/need to. Sometimes, thankfully rarely, you have to resort to "bear skins and stone knives" to practice your craft.


      Peter L. Berghold -- Unix Professional
      Peter at Berghold dot Net
         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.
Re: Thoughts on script portability
by jdtoronto (Prior) on Jan 25, 2004 at 03:41 UTC
    I have had small clients in a variety of situations not unlike those you refer to. On some ocassions, it has been me who has taken the walk becuase I just don't want to deal with un-cooperative hosting outfits. In other cases, I have not found it difficult to move small clients to servers that I control - this tends to make it very easy!

    Larger clients tend to be much easier to work with. Either we end up providing hosting services or we have clients who already have facilities with companies like Q9 Networks who might be expensive, but boy are they easy to get along with.

    However, I do note your apparent concern about the way we sometimes respond to Monks who are having difficulty in this regard. Some Monks do assume that "anything will build", and I have seen people get unhelpful responses here when they are having those types of problems. The same question asked by the same person in a module specific mailing list will receive a much better response.

    jdtoronto

Re: Thoughts on script portability
by hardburn (Abbot) on Jan 25, 2004 at 04:35 UTC

    You don't have shell access to the target machine?

    Ask someone who does to install the module. If you can't do that, you can settle for copy-and-pasting the bits of code you need. Hardly an ideal solution, but it's still better than re-inventing your own stuff.

    You lack compiler tools for the target machine?

    In your case (GNU/Linux development, Windows target), you might be able to do some fancy tricks with a cross-compiler using Cygwin's stuff. Also Wine might help. People often think of it as a way to run Windows programs on GNU/Linux, but it's also designed for porting programs between those platforms.

    Uncooperative hosting facility

    If I was a direct employee of the company instead of a consultant, I would strongly urge the group to find a new host. My view is that as an employee, I have to speak up when I see something wrong, but as a contractor, I'm there for the whims of the company I work under. The most I would say is that it may take me longer to work around the problems caused by not having access to various modules and let them work out if its worth it or not.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

          Ask someone who does to install the module.

      Thought of and tried. The client I am referring to had an extremely uncooperative hosting site. In fact they got quite combatitive with me over the issue. They were MS VBScript biggots and didn't want to even support Perl.

      Sad side-story to all this was that they had a server crash on the machine that hosted my client's web site. When they rebuilt the machine the did not re-install the Perl interpreter. This went on for several months before we got any cooperation out of them to re-install Perl.

          I would strongly urge the group to find a new host. In your case (GNU/Linux development, Windows target), you might be able to do some fancy tricks with a cross-compiler

      This option was considered at the time. I must confess though I did not persue it because I wanted more to bring the point home to my client that he needed to get onto a better hosting facility. The one he insisted on staying with was not serving his needs.

          I would strongly urge the group to find a new host.

      In the end the relationship I had with this client ended badly unfortunately. The client's position at the time (a very small cap business) was that was the hosting facility he picked and that was that. We parted company and interestingly enough the client changed providers twice over the last few years and is now with a very progressive provider.

      Client's name, of course, is being withheld for obvios professional reasons.


      Peter L. Berghold -- Unix Professional
      Peter at Berghold dot Net
         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.

        You know, it's really easy to focus on money and say, "I want this client because I want the cashflow assosciated with their business." Sometimes you need to just stop and think, and say, "Is it worth working with this client?". That may be really hard to do sometimes in today's job markets, but there are a lot of bad clients out there who will cause you more problems then they are worth. I learned this myself the hard way after I got burned several times. So instead of focusing on how to bend around 2nd rate hosting services, you may want to be glad that the client left you when they did. After all, maybe they would have caused you more problems then they are worth.

Re: Thoughts on script portability
by Abigail-II (Bishop) on Jan 26, 2004 at 00:44 UTC
    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
    What's the problem here? On my box, I run hundreds of programs who use hundreds of libraries and modules, all written by a cast of thousands. None had shell access to my machine. That's why software comes with a setup procedure. Whether it's called ./configure; make; make install, setup.exe or packageadd.
    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.
    Well, that's your problem. And a serious one. Even if you were to write 100% pure Perl, it means you roll out software that you haven't tested on the target platform. Remind to never do business with you.
    Uncooperative hosting facility.
    Then take your money elsewhere.

    I don't see that Perl or CPAN needs to solve any of the problems you mention.

    Abigail

Re: Thoughts on script portability
by l3nz (Friar) on Jan 26, 2004 at 12:50 UTC
    I noticed the same thing when I first started writing CGI apps in the mid to late 90's. I guess that the success of PHP as an alternative to Perl is mostly linked to its ease of redeployment on different hosts. All that the average person needs to build a dynamic web site with a database back-end is already buried in.

    With CGI - and worse, FastCGI or mod_perl and mod_rewrite like some infamous templating systems I won't mention here - switching from a host to another can be a royal PITA, unless you have a good degree of control on the target machine and on all the needed modules.

    I love Perl and loathe PHP when you need to solve a computing problem, but most of the time building average web sites with PHP is simply more sensible. (This is not a flame bait - I wish I could use Perl instead...)

Re: Thoughts on script portability
by Sol-Invictus (Scribe) on Jan 26, 2004 at 14:18 UTC
    It's refreshing to read a topic like this, I tend to find this line of thought is automatic flame bait in some circles (which shall remain nameless).

    I agree with you in that necessity dictates everything, even core modules started out as someone needing to do something bad enough. I would also like to add one further point to what you said blue_cowdawg - modules make you user not a programmer.

    Yes, there are times when you have a deadline to meet and the modules are there, but if you have time why miss out on the opportunity to learn something new?

    Of course the counter replies run thus:
    maintenance - if something changes you'll have to update your custom module

    testing - modules on CPAN have been tried and tested by loads of peeps

    optimisation - CPAN modules have been optimised (inferred by people who know how to do that)

    and of course "don't re-invent the wheel".

    But what the hell, say I, if you have time and the inclination, try and build an SMTP server using the socket module - you might not finish it, but (I believe), like a pilgrimage, the journey is worth more than the destination.

Re: Thoughts on script portability
by Stevie-O (Friar) on Jan 29, 2004 at 02:06 UTC
    I wholeheartedly agree you on this.

    I live in a world that most people tend to gloss over -- the world of Win32. Most of the Linux/Unix/etc. zealots will refuse to even try supporting Win32, but the fact is, Windows is damn near everywhere. I recently tried to install a module (I can't remember which one) that was pure Perl, yet failed under Win32. The reason? Instead of using the portable Cwd module and calling getcwd(), the module's testcase did this:

    $cwd = `pwd`;
    That works great on any system that has a 'pwd' program, or a shell that provides a 'pwd' builtin. However, no such program or builtin exists in Win32. As a result, the module failed its tests.

    Another common one I see is explicit references to /tmp in testcases.

    XS isn't hard to get right, either. I know, because the first time I tried doing it, I was amazed at how it worked flawlessly (creating a .dll instead of an .so).

    </my_$0.02>

    --Stevie-O
    $"=$,,$_=q>|\p4<6 8p<M/_|<('=> .q>.<4-KI<l|2$<6%s!<qn#F<>;$, .=pack'N*',"@{[unpack'C*',$_] }"for split/</;$_=$,,y[A-Z a-z] {}cd;print lc
Re: Thoughts on script portability
by mnc (Beadle) on Jan 31, 2004 at 08:55 UTC
    You raise interesting issues. For instance, I've never seen documentation on cross-compiling with perl and cpan. And testers.cpan's testing of Windows could certainly be more pervasive, and broader (eg, ActiveState perl, ActiveState with their precompiled modules, ActiveState with M$ VisualStudio, gcc-built perl with raw Windows, with cygwin, with mingw, and all under Win98/2k/CE/etc).

    As pointed out, some other languages provide better cross-platform and Windows support. Tcl makes it easy to create a stand-alone Windows executable containing a collection of source files which look to themselves like they are living in a normal filesystem (ie, www.equi4.com/starkit.html). Easy even from Linux.

    Perhaps perl developed among "people with root access", and tcl among "less privileged users"? Or for "systems you have access to" rather than "tossing apps into the unseen wild". Or for "real" OSes? Or perhaps ActiveState blocked the upstream presure to make perl more portable?

    Still, how difficult would it be to create a starkit equivalent for perl...? Perhaps the perl community just isn't trying? ;)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://323886]
Approved by Corion
Front-paged by Courage
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (8)
As of 2014-07-24 03:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (156 votes), past polls