How Do I Turn Custom Modules into CGI Script?

socrtwo has asked for the wisdom of the Perl Monks concerning the following question:

I have a web service which which extracts the text from OOXML and ODF files. I have some extra codes which provides another method for extracting the data from XLSX files and converting it to CSV files. However the code uses two custom Perl modules, which I don't think my web hoster will want to install.

What is the best way to convert modules to Perl script? Is it just to make the sections of the modules used, into subroutines?

Comment on How Do I Turn Custom Modules into CGI Script?

Replies are listed 'Best First'.
Re: How Do I Turn Custom Modules into CGI Script? by nedals (Deacon) on Aug 06, 2009 at 17:07 UTC
use lib is your friend. `use lib "/path/to/modules/";` [download]	[reply] [d/l]
Re^2: How Do I Turn Custom Modules into CGI Script? by socrtwo (Sexton) on Aug 10, 2009 at 00:29 UTC
Sounds like a very valuable comment that newbie like me needs to hear :-).	[reply]
Re: How Do I Turn Custom Modules into CGI Script? by metaperl (Curate) on Aug 06, 2009 at 16:52 UTC
Can you copy them into your web tree somewhere? Also, I think its best to get a hosting service where you have full control of what is installed and free yourself from the control of others.	[reply]
Re^2: How Do I Turn Custom Modules into CGI Script? by socrtwo (Sexton) on Aug 10, 2009 at 00:30 UTC
I know it's not so cool to name names, but are there any you would recommend? This sounds like an unusual hosting arrangement. For instance is DreamHost a company like this?	[reply]
Re^3: How Do I Turn Custom Modules into CGI Script? by ww (Archbishop) on Aug 10, 2009 at 01:21 UTC
Not exactly, but they were very cooperative about installing modules beyond those on their basic list. (FWIW, my experience w/DreamHost was pretty good except for some horrors in assuming responsibility for a client's site -- for which the client had neglected to obtain account-change authority or passwords from a webmaster who subsequently went AWOL). But other hosting providers are also cooperative; since we have named one name, here's another: HostRocket which is generous with shell access, as well. Turning back to metaperl's "full control" suggestion: that phrase implies, to me, a dedicated server. That's considerably more expensive than shared hosting, but is frequently well worth the cost (of course, the reverse is also often true).	[reply]


Just another Perl shrine
	PerlMonks