Unless it's an XS file, I'd just copy it and set 'use lib'
to point to it. Or copy the module into your CGI script, heh. | [reply] |
Even if it is an XS based module you can do this,
providing:
a) you have access to a compiler
i) on that machine
ii) elsewhere to (cross-)compile for that platform
b) the ISP is not using multiple heterogenous
servers with a networked filesystem (the binary
module being useless on other platforms).
--
perl -p -e "s/(?:\w);([st])/'\$1/mg"
| [reply] |
Is it a module that you can simply install the .pm file in the local directory then refer to it appropriately, or does it require some compilation? As others said a little earlier (and better than I could have), there are ways even if they must be confined to your directory.
Having worked at an ISP as one that dealt with both security and server issues, I can understand what they are saying. A security breach could lead to liabilities for them, and often times the server administrators (or as likely, the single administrator) are/is busy enough not to have much (if any) time to look at the module to determine what issues, securit and otherwise, might be involved (and that assumes s/he has the ability to understand the code involved in the module).
Based on my own experience, I would suggest the following. Take the time to provide them with information about the modules and what is involved (both install and security), and possibly even offer to let them contact you if they have questions regarding it. By doing so, you help yourself by showing them you are a professional, you help alay their concerns, which may result in them being more willing to work with you, and you open a dialogue that could possibly be helpful down the road even.
One thing I absolutely would NOT advise would be to try to manipulate their install on the remote box covertly using some techniques I have found while wandering around the Monestary recently. At least contact them and ask if you can attempt to install it in your local directory, letting them know what you are considering. There always exists a chance that something could go wrong, and if so, and if it were to be traced back to you, they would be well within their rights to terminate your access, your account, or possibly even file charges or attempt to recoupe damages. Should something like that happen, it would damage both your reputation and theirs, and would likely cast a shadow on their future dealings with programmers and developers.
I hope monks of more experience than I will comment on this as well with their views and experiences, as I can only comment from my limited quantities of these. In any event, good luck with the project, whatever it be.
| [reply] |
Thanks atcroft for the advice. Unfortunately, what I require (or want) atleast is mime::tools which seems to be quite a complicated set of modules. Also my perl skills are somewhat limited, and so I find it easy to use a module, but quite often get myself confused when getting to complicated. One suggestion that I read was to include the code in my script. This seems extremely complicated, and besdies I wouldn't really know where to start.
Thanks for the advice, and I will try talking to them again.Regards,
Gerard.
| [reply] |
Another way that will work with some providers is to set an environmentvariable PERL5LIB to the path where you want to install the Modules (somewhere in your home) and then install them there.
A better way might be if it was possible to put it into a directory of your home, find the path of the current running script with use FindBin qw($Bin); and then load the Module with use lib "../../myModules"; and require MyModule and, if needed, import. Sometimes it might help if you do so in a BEGIN-Block...
But I consider talking with the provider a better way ;-)
Best regards,
perl -e "print a|r,p|d=>b|p=>chr 3**2 .7=>t and t" | [reply]
[d/l] |
As mentioned, as long as you have access to the tools necessary to
build the module, you can install it into your own private lib
directory. CPAN style modules already have support for this
in their Makefile.PL. To take advantage of it, use the PREFIX setting:
[user@host modules]$ tar xzvf Module-1.0.0.tar.gz
[user@host modules]$ cd Module-1.0.0
[user@host Module-1.0.0]$ perl Makefile.PL PREFIX=$HOME/mylib
[user@host Module-1.0.0]$ make && make test && make install
[user@host Module-1.0.0]$ make && make test && make install
[user@host modules]$ rm -rf Module-1.0.0
Then (again, as mentioned) add a 'use lib' to your program:
#!/usr/bin/perl -T
use strict;
use warnings;
use lib '/home/user/mylib/lib/site_perl/5.6.0';
use Module;
...
Just remember that you have to have the 'use lib' statement
before the 'use Module;' statement.
Updated: Based on other feedback, I'd like to clarify
that this technique can be used on a local system to
create the install
(if the system is binary compatible with the remote
system,
then it should even work for XS based modules) and then
recursivly copied (ncftp is great for this) to the remote system.
amelinda - Thanks for pointing out that I missed the ftp only access. | [reply]
[d/l]
[select] |
That won't work here, since he specified that he only had FTP access. Otherwise, a reasonable approach.
| [reply] |
For anyone that is interested....
I got around the problem by changing to a much more reasonable ISP.
Cheers for all the advice, Gerard. | [reply] |