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.

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

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

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.

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.

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.

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

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`;
[download]

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>

$"=$,,$_=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
[download]

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? ;)

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 don't see that Perl or CPAN needs to solve any of the problems you mention.

Abigail