I have installed perlbrew which seems like a good solution, but I get some meaningless error when actually trying to install some Perl version:
$ perlbrew install perl-5.12.1
Attempting to load conf from /home/dave/perl5/perlbrew/Conf.pm
Fail to get http://search.cpan.org/dist/perl-5.12.1 (error: ) at /home/dave/perl5/perlbrew/bin/perlbrew line 1277.
Based on your comments do you have http_proxy ENV variable set in your shell?
$ env | grep http_proxy
If not then set it with your proxy settings and re-try perlbrew install:
$ export http_proxy = "http://yourProxyURLorIP:8080"
$ perlbrew install perl-5.12.1
perlbrew uses this ENV variable to pick up the proxy server. If this ENV variable isn't set then it tries the normal direct HTTP connection (see line 1274 in perlbrew current master on Github)
$ua->proxy($ENV{http_proxy}) if $ENV{http_proxy};
If that doesn't work then have a look at HTTP::Lite. This is what perlbrew uses under the hood to fetch source code. NB. perlbrew uses its own copy of HTTP::Lite
Finally if still no luck you mentioned that you "first installed it" via CPAN. The docs does mention issues when upgrading from a previous CPAN version. This maybe something further you need to look into?
Update Test this HTTP::Lite script and let me know what you see (NB. You may need to install HTTP::Lite):
use strict;
use warnings;
use HTTP::Lite;
my $ua = HTTP::Lite->new;
$ua->proxy("yourProxyURLorIP:8080"); # <= http_proxy env minus "http://"
my $req = $ua->request( 'http://search.cpan.org/dist/perl-5.12.1/' )
or die "Unable to get document: $!";
print $ua->body(); # <= if you get this then all is good!
I think you've probably been hit by a known bug with HTTP::Lite, see RT issue uri style proxy env vars fail to set the proxy and port correctly.
The above code is the workaround to this bug. I assume the same bug is in perlbrew copy of HTTP::Lite. If it is then removing the http:// from your http_proxy ENV would resolve the problem (famous last words!)
Update 2
Just to make my last comment clear when you run perlbrew you can do this (from shell like bash):
http_proxy=IPaddr:Port perlbrew install perl-5.12.1
You would need to always prefix every perlbrew command like this, at least until HTTP::Lite or perlbrew proxy bug is fixed.
Alternative to above is you can just patch your local version just be adding the following before line 1277:
$ENV{http_proxy} = "IPaddr:Port"; # <= your proxy IP & port
Hopefully we've finally cracked it! Let me know if all successful because if so then I'll post a fix to Gugod (author of perlbrew) with necessary local changes to HTTP::Lite.
Related
I have 2 versions of perl installed. perl v5.18.2 and v5.20.0 . But when I do perl -v I get perl v5.18.2. I don't need v5.18.2 at all. I need v5.20.0. How do I change the path to include v5.20.0 and not v5.18.2?
Here is my $PATH:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
v5.18.2 is installed at /usr/bin/perl and /usr/bin/perl5.18.2, and v5.20.0 at /root/perl5/perlbrew/perls/perl-5.20.0/bin/perl.
See the perlbrew documentation:
switch Permanently use the specified perl as default
perlbrew switch perl-5.20.0
If you haven't already, you will need to add source /root/perl5/perlbrew/etc/bashrc to your login script for this to work.
The following will add the desired build of Perl to the search path so that it's found first:
export PATH="/root/perl5/perlbrew/perls/perl-5.20.0/bin:$PATH"
You may add that to your login script to make this change permanent.
Note that you'll need to update the shebang (#!) lines of scripts installed with a different perl to the following:
#!/root/perl5/perlbrew/perls/perl-5.20.0/bin/perl
It looks like you have three copies of perl installed, as neither of the paths you mentioned are in the PATH variable yet your shell still finds one
There's no need for perlbrew. All you need to do is set your PATH variable on the command line
$ export PATH=/usr/bin/perl5.18.2:$PATH
If you want to make that change permanent then add the command to your profile file at ~/.profile
Normally in linux Debian we do sth like this to install a package non-interactively e.g
sudo apt-get install -y Package_x_z
#[-y --assume-yes]
How we can do the same while installing a perl module e.g
sudo perl -MCPAN -e 'install DBI'
That prompt is (typically) coming from ExtUtils::MakeMaker's prompt() function. Stick export PERL_MM_USE_DEFAULT=1 in your .bashrc (or equivalent for your preferred shell) to stop the prompts. The ExUtils::MakeMaker man page documents it thus:
PERL_MM_USE_DEFAULT
If set to a true value then MakeMaker's prompt function will always return the default
without waiting for user input.
Note that this can come to bite you if you run cpan(1) on a box that's not yet had CPAN repositories configured. It will rattle on and get stuck in a prompt loop at a point where there is no default and you need to make a choice, but have no ability to do so. export PERL_MM_USE_DEFAULT=0 in the shell before running cpan(1) will of course temporarily re-enable input.
To prevent the CPAN client from asking whether to install prerequisites, start it in interactive mode
perl -MCPAN -e shell
and enter the commands:
o conf build_requires_install_policy yes
o conf prerequisites_policy follow
o conf commit
The commit command is optional, but it will update the default configuration, which I suspect is what you want. Without it, you may or may not (depending on whether autocommit is enabled in your CPAN config) need to make this change every time you want to do a prompt-less installation.
These changes will deal with all of the CPAN client's routine questions about whether to install dependencies. For distributions which have questions embedded in their install scripts, you may also want to add
o conf inactivity_timeout 60
to set how long it will wait for a response before automatically going with the default answer to the question. (Set it to 0 to change it back to "wait forever".)
What about just :
$ yes | sudo perl -MCPAN -e 'install DBI'
Ban ! your problem is solved :-)
Appending to an answer here, you can also make these changes in config file located at /usr/share/perl5/CPAN/Config.pm.
'build_requires_install_policy' => q[yes],
'prerequisites_policy' => q[follow],
This helped me to automate installation, since CPAN doesn't have these configuration by default.
I have installed ActivePerl 5.14.2 on a Windows 32 bit machine running XP. My problem is that I'm trying to install a few modules with PPM and it's not working out.
According to ActiveState's website, all you need to do to install a module from their repository is "ppm install module name" , example: http://code.activestate.com/ppm/Template-Toolkit/
Every time I try this or any other module I get: "No Perl script found in input"
Even when I do just "ppm" I get the same message, even though the GUI should run.
When I run PPM with a GUI from the start menu I get this error: "Failed 500 Can't connect to ppm4.activestate.com:8080 (connect: timeout)”
I though that it might be my connection, so using cmd.exe I used the set HTTP_PROXY command and then tried ppm install, but still no luck. So is there any way I can get these modules installed?
Any advice is appreciated !!
Invoke the cpan prompt from your command prompt. Go to cmd and simply type cpan. If you successfully enter cpan prompt them there is probably no issues with your Perl installation. To install a module from cpan prompt just use
cpan>install Module::Name
Screenshot below shows command to install module Net::Stomp
If the above does not work, check if your FTP data and connection ports needs to be added to the Windows firewall exceptions (Ports 20 (FTP Command port) and 21 (FTP Data port)).
Alternatively (if you don't want to add port 20 21 to exception), you can go to the cpan prompt and use an ftp_proxy by
cpan> o conf ftp_proxy http://your.ftpproxy.com
and then issue install command. Or you can update your ../CPAN/config.pm file to make permanent changes to the ftp_proxy parameter.
The next step would be to try set the FTP_PASSIVE mode to 1. By default the libnetcfg configuration for this is set to 0. To change this find libnetcfg.bat file (should be somewhere C:\Perl\bin), open the file in an editor and replace
ftp_int_passive 0
to
ftp_int_passive 1
Again, looking at you r timeout error it seems that your network is blocking you from accessing the CPAN ftp mirrors, this would happen mostly if you are inside a corporate VPN. The solution to this can only be proxy servers.
I'm trying to write a perl script that redirects its stdin to a remote machine and at the same time redirects the stdout of the remote machine to its stdout:
callingProgram <--> myScript <--> sshTunnelToRemote
See this question and bdonlan's answer for the purpose of the script.
First I tried to use the open2() function from the IPC library but for reasons described here it doesn't seem to be a good approach, I didn't even get a simple grep command working.
My second idea was to use the Net::SSH::Perl or the Expect libraries but they're not available on the machine where the script is supposed to be executed and I can't install libraries there.
So my question is what could be a simple way to achieve what I want? Solutions using [ba]sh or even C++ are also possible. The targeted platform is Solaris 10.
Seems like you could probably get away with nothing more than system() — don't pass the data from your stdin to ssh's stdin and from your stdout to ssh's stdout; just let ssh inherit your stdin and stdout. Unless you need to modify the data in transit somehow.
cpanminus can do this for you
Running:
cd ~/bin
curl -LO http://xrl.us/cpanm
chmod +x cpanm
Now you can try your problem using the right tools (e.g. Net::SSH::Perl).
The power of perl is cpan, and cpanminus gives you the ability to install whatever you need even if you don't have permission to install to the system-wide libraries.
Read the module documentation for the full details.
I am getting the following error connecting to an Oracle 11g database using a simple Perl script:
failed: ERROR OCIEnvNlsCreate. Check ORACLE_HOME (Linux) env var or PATH (Windows) and or NLS settings, permissions, etc. at
The script is as follows:
#!/usr/local/bin/perl
use strict;
use DBI;
if ($#ARGV < 3) {
print "Usage: perl testDbAccess.pl dataBaseUser dataBasePassword SID dataBasePort\n";
exit 0;
}
my ($user, $pwd, $sid, $port) = #ARGV;
my $host = `hostname`;
my $dbh;
my $sth;
my $dbname = "dbi:Oracle:HOST=$host;SID=$sid;PORT=$port";
openDbConnection();
closeDbConnection();
sub openDbConnection() {
$dbh = DBI->connect ($dbname, $user ,$pwd , { RaiseError => 1}) || die "Database connection not made: $DBI::errstr";
}
sub closeDbConnection() {
#$sth->finish();
$dbh->disconnect();
}
Anyone seen this problem before?
Check your Oracle client configuration (including, as the message says, ORACLE_HOME), check file permissions, etc. It's unlikely that DBI per se has anything to do with the problem, and I know for a fact that DBD::Oracle is compatible with the 11g libraries (at least the 11g InstantClient).
Install the perl module DBD::Oracle
Add use DBD::Oracle; into your perl script.
This made the problem go away for me.
Afther upgrade Oracle form 10.2.0.4 to 10.2.0.5 my Perl-CGI not working, the error.log file of Apache was the error:
DBI connect('DB','user',...) failed: ERROR OCIEnvNlsCreate. Check
ORACLE_HOME (Linux) env var or PATH (Windows) and or NLS settings,
permissions, etc. at ...
OCIEnvNlsCreate. Check ORACLE_HOME (Linux) env var or PATH (Windows)
and or NLS settings, permissions, etc.! at ...
adding the following directive solve the problem:
my $ORACLE_HOME = "/usw/app/oracle/product/10.2";
$ENV{ORACLE_HOME}=$ORACLE_HOME;
Sorry for bringing this thread alive again, but I've been trying to solve this issue for weeks. Nowhere did I find that what finally solved it for me.
Environment: RedHat 6.5, Oracle Instant Client 12.1, Apache 2.2
What solved it for me:
Change the permissions of the directory where Oracle Instant Client is installed., which must also be the value of LD_LIBRARY_PATH. The directory wasn't accessible to "other", just owner and group. This command made the whole difference:
# chmod o+rx INSTANTCLIENT-DIRECTORY
I had been trying to create every possible combination of ORACLE_HOME and LD_LIBRARY_PATH. (Even "unsetting" ORACLE_HOME; I found suggestions that would solve the issue, since Instant Client needed only LD_LIBRARY_PATH and !NOT! ORACLE_HOME.) Nothing helped, until ...
it hit me to look further in the error message:
failed: ERROR OCIEnvNlsCreate. Check ORACLE_HOME (Linux) env var
or PATH (Windows) and or NLS settings, permissions, etc.
permissions being the key word!
Hope this helps someone else!
2021 Update for CentOS 8 etc:-
If you use systemctl, nothing in your environment or Apache setup can pass environment vars to DBI!
you need to edit the /usr/lib/systemd/system/httpd.service file and add appropriate lines like this after the [Service] section:
[Service]
Environment=ORACLE_HOME=/opt/oracle/product/19c/dbhome_1
Then re-start apache as usual:-
/bin/systemctl restart httpd.service
(Vote this up if it helped you: this web page is the #1 google result for this old problem which systemctl "security" has rebirthed)
Check the #!/usr/bin/perl (first line of your script) is the right perl version you wish to use too !
Previous answers don't solve this problem, but they did point me in the right direction: The launched environment was missing the DYLD_LIBRARY_PATH for Oracle instantclient. You can check by calling: launchctl export
or
launchctl getenv variable_name in OS X 10.10
I compared the output from my .bash_profile and found that the path to instanclient wasn't in launchctl PATH and DYLD_LIBRARY_PATH - Once I added them with the following it worked:
launchctl setenv PATH /path/to/instantclient
launchctl setenv DYLD_LIBRARY_PATH /path/to/instantclient
The environment variable used to specify the Oracle libraries may be different from one system to another. On most systems, use LD_LIBRARY_PATH but it may also be LIBPATH (notably on AIX), DYLD_LIBRARY_PATH, or maybe others.
I too went through the same issue. In my case ORACLE_HOME environment variable was incorrect.