Net::SSH::Perl and the @INC path

Posted by on 2017-01-04 11:44
Forums: PPM | OS: Windows 7


Been out of Perl for a little while now, change of job so I need to pick it back up. I have a few old Net::Telnet scripts that I'm converting over to SSH and need the Net::SSH::Perl module.

I can't get it through PPM but I can through CPAN, so using the built in cpan script I upgrade CPAN and pull down all the dependencies for Net::SSH::Perl and the CPAN module itself.

The problem I am seeing is one of PATH for the Include function - @INC is aligned with PPM installs and the cpan module now installs to a totally different PATH that is not multi module aware.

Net::SSH::Perl is in C:\Perl64\cpan\build\Net-SSH-Perl-2.01-FG1pJs\lib - use the -I to set path and it comes up with an Include error for the dependent Crypt::PRNG module which CPAN put in C:\Perl64\cpan\build\CryptX-0.044-DGt4Jb\lib

This is a new ActiveState 5.24 install on 64bit Win7

Sorry for the newbie-ish PATH question ... any pointers would be appreciated.

Thanks - Mike

ActiveState Staff
Fri, 2017-01-06 11:26

Are you sure you can't use Linux? No other operating system makes this module easy to build...

On Win32, open and unresolved for seven years:

No successful test reports from module testers on any version of Win32 Perl since the 1.42 release;maxver=1

I think that upgrading "cpan" might have broken the PPM setup. (@INC has been heavily worked on with the 5.25/5.24RCs in the last few months, and it's rather likely that code all over CPAN has been modified to accommodate one or more of the several variants on a core fix for @INC that will not be included in 5.24.1 after all.)

You can remove the CPAN update from the "site" area and fall back to the "as-shipped" configuration, but that might not be the only issue. I've seen modules make "weird" assumptions before. Sometimes that's because the module code assumes that if you're on Windows and running the cpan script (or if the compiler is a GCC), you must be using Cygwin/CygwinPerl. SSH modules are likely to have that assumption, since Windows itself has no SSH support and Cygwin has long been the only way to get SSH support on Windows.

Cgywin might be a way forward for you.

pachecom@southc... | Fri, 2017-01-06 13:24

Thanks for the comment, I thought windows might be a PIA for this but it's what I have right now. Figures Window$ is all but abandoned for Perl support since powershell .. not suprised there.

I managed to get space on a centos 6 box but the admin wants me to keep my cpan modules private and I'm running into the same problems. reading through a thread on local::lib as a possibility but I'm still not sure.

perl5 installed with the @INC being /usr/share/perl5, but all my cpan modules are in my home directory under /home/uname/.cpan under the build folder with a unique folder name per module.

Like NET::SSH::Perl is in Net-SSH-Perl-2.01-21Ayw5 with lib and blib under that folder. I was thinking about doing a simple ln -s to the @INC home, but I would have to do one for each module and that is messy and just does not seem right to me ... I really don't want to install anymore modules until I clear the path issue for module resolve up.

If you have any ideas please let me know, thanks again, back to banging my head against the wall. :)

ActiveState Staff
Mon, 2017-01-09 12:17

Best solution is to install a different, "personal" Perl under your own home directory. That's what ActivePerls on Linux do, and it gives you high levels of insulation from the system Perl. However, there isn't an ActivePerl Community Edition you can use with CENTOS 6 (too old...), and RPM sure won't do that for you.

You probably won't be allowed to install PerlBrew either:

If you're stuck using the system Perl:
Set up a local PERL5LIB variable in your shell .profile (bash?) so that PERL5LIB points to your personal module area before you run Perl. PERL5LIB settings will take precedence over all existing entries in @INC.

That avoids messing with the System lib or site folders and won't affect any other Perl use. I wouldn't try to second guess the necessary folder structure, or impose an existing one. I would set up an empty branch (without hiding the folder) and let the cpan script and Perl set up the tree.

Note: If you really get stuck, you can try something similar with the dynamic library loader path and the LD_LIBRARY_PATH value in your .profile. I don't like to recommend that, ever, but you might have a case where there are version conflicts with other libraries supplied by the system, and you need to create your own shared library pool too. It's not unlikely... CENTOS 6 is a very conservative platform. Newer Perl code may require versions of third party and C libraries that are unsupported for CENTOS 6. If it comes to glibc, tho, you have to bit the bullet and use something like Ubuntu 14 or 16.