-
Notifications
You must be signed in to change notification settings - Fork 822
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Perl Modules #186
Comments
Thanks for trying this out. Could you collect a strace for the 'perl Makefile.PL' command and see why it is complaining? |
What version of ExtUtils::MakeMaker is installed? |
...and what version of ExtUtils::Manifest? and then, can you try again with updated EUM+EUMM and see if the outcome is different/better? |
Just commenting to keep microsoft updated on the issue so it doesn't look like a tumbleweed. Issue has been reproduced using Perl 5.18.2's File::Find ( which there is no upgrade path for without an upgrade of Perl itself ).
^ Shows only top level entries, fails to recurse.
^ However shows entries recursively. |
Perl 5.18.2 I downloaded 7.1 and ran the following with the same result:
This, however, shows all of the files:
|
I forgot to mention that the version of ExtUtils::Manifest is 1.63 |
Well, doing the following will allow users to install modules:
This is just a work-around. |
Latest Perl resolve File::Find problem? Or problem is the implementation of hard link in "bash on windows" ? |
A better patch than editing /user/share/perl/5.18/File/Find.pm is to change line 94 in /usr/lib/perl/5.18.2/Config.pm to: |
This is great way! This is easy and better! |
Improve the way to install cpan module.
|
I'm not quite sure which is better. The first way doesn't result in requiring Config.pm at all. I'm not aware of anywhere else that uses the That being said, I updated the work-around to show both methods. They're both a really easy one-line |
I apply the above patch, and install some modules. Installation of IO::Socket::IP 0.38 fail.
|
@yuki-kimoto That module not installing is a different thing entirely. For module support, you should really take this discussion to IRC: |
What is the Microsoft / Unbntu plan for this? Seems like the ideal think would be to make |
Actually the ideal situation would be that File::Find detects that nlink can't be used, and disables it for us. nlink in File::Find breaks with many file systems, including ISO9660. Which is why File::Find tries (and fails on WSL) to figure out whether nlink can safely be used, and disables it if not. In a discussion from 2000, Randal L. Schwartz said: "If you find an architecture on which you need to set this manually, please report it to the developers. This is supposed to be set automatically on those system which need it. If it isn't, it's a bug." Ideal situation? File::Find figures out to disable nlink when running on WSL. Whether that requires a change to File::Find or to WSL I wouldn't hazard a guess. It could be that File::Find's nlink detection is thrown off because it doesn't expect to be in a "Ubuntu on Windows" environment, in which case File::Find would need to change. It could be that File::Find's nlink detection doesn't work because WSL delivers the wrong answers to the tests File::Find makes to see whether nlink is supported, in which case WSL would need to change. |
I see your point. Looking at the
Of course when I run: I had a similar problem in my own
The problem with this code is that someone may change their Windows folder to another location, but WSL doesn't have access to the windows environment variables to check for %WINDIR%. Apparently some newer development versions of WSL support calling cmd.exe from inside WSL, so that may provide a better solution. |
@ryanerwin Thanks for digging and finding that! We can positively detect WSL via /proc/version and MS states they can't see a situation where they'd change that. See #423 Do you think checking for the presence of "Microsoft" or "WSL" in /proc/version just for nlink is the right way to go? If /proc/version is the right way to go here, I can create a pull request with it for File::Find (assuming that lives on GitHub). |
Okay I have something that works. Edit: That code was nonsense, that's not how index() works. Fixed code further down. |
I've made the IRC channel aware of the discussion, but it can't hurt to start a mailing list discussion with the group about it. |
Thank you @genio! I sent something out to the mailing list. |
Upon discussion in the mailing list, here's the code. This would go into /usr/share/perl/5.18/File/Find.pm .
|
@genio, P5P maintainers are a friendly and gracious bunch. I've received help and direction to satisfy the Ubuntu perl maintainers first, then they can submit upstream to P5P. I've filed a bug for this in the Ubuntu system: https://bugs.launchpad.net/ubuntu/+source/perl/+bug/1647120 |
How is this handled in find(1)? I would expect it to be broken too when not using |
@Leont I'm not quite sure. I tried to go through the util.c in find(1), but I'm a bit lost as to how the auto-detection works. I know oldfind.c reads the entries, checks, and if stat doesn't match up, set's -noleaf automatically. |
James E. Keenan has a patch for this that also tidies up how dont_use_nlink is set. https://rt.perl.org/Public/Bug/Display.html?id=130258 |
File::Find also tries to detect this, in particular the nlink logic is disabled if is sees a directory with less than 2 links, but apparently it isn't triggered in this particular case. |
Confirmed that this issue is also present in WSL Insider build 14965 with Ubuntu 16.04 LTS and perl v5.22.1. As we expected it would be, just crossing t's and making sure. |
#910 might mean this gets fixed in WSL. It's not fixed there now, mind you, as far as I can tell. But if WSL learns how to handle the nlink hack, efforts to change File::Find should probably stop. |
Can someone tell me what the link count of such a directory on WSL is? ( Is the former the constant for different directories? Is the difference constant? |
And Ryan's way:
|
Here you go:
|
Ryan, which build is this? I'm a slightly older one, 14965 (because UUP work that started Friday the 2nd, all I had was ISO), and I'm getting 0 links for directories. If this is fixed that'd be great news. Can you try:
And see whether it works recursively in your build? Assuming you didn't change don't_use_nlink that is, if you did, that will of course work. |
I think I have to walk my statement back. Upon further testing, recursive File::Find appears to work in my build, and I can install modules from cpan. I fiddled with File::Find previously, but best as I can tell, I have removed those changes and dont_use_nlink is not being set manually. It'd be good to have that confirmed. |
A link count of Having |
Right. So that'd mean my testing yesterday evening was sloppy, and MS did fix this in an insider build by forcing the link count to 0. |
I've been testing on the default "Anniversary Edition" version of WSL, and switching between the default Ubuntu image and a CentOS 7 image. When Config.pm:
When Config.pm
|
Thanks @ryanerwin ! I think that's conclusive. In my system,
That'd mean MS has fixed it in Insider build, and therefore in Creator's Update, and my whole push towards changes in File::Find was misguided. |
@ALL As of build number 14986 I am no longer able to reproduce the original error that spawned this thread. Based on @yorickdowne 's comment above it looks like this issue has been fixed. Feel free to reopen if I am closing prematurely. |
I'm having trouble using Perl modules, tho I couldn't see any obvious problems with them being installed. I previously installed the Crypt::HXSKPasswd module without kenny@LT-NYC123:~$ hsxkpasswd
hsxkpasswd: command not found
kenny@LT-NYC123:~$ sudo cpan Crypt::HXSKPasswd
[sudo] password for kenny:
Loading internal null logger. Install Log::Log4perl for logging messages
Reading '/home/kenny/.cpan/Metadata'
Database was generated on Fri, 19 Oct 2018 15:17:03 GMT
kenny@LT-NYC123:~$ hsxkpasswd
hsxkpasswd: command not found
kenny@LT-NYC123:~$ cpan --help
Loading internal null logger. Install Log::Log4perl for logging messages
/usr/bin/cpan version 1.64 calling Getopt::Std::getopts (version 1.12 [paranoid]),
running under Perl version 5.26.1.
Usage: cpan [-OPTIONS [-MORE_OPTIONS]] [--] [PROGRAM_ARG1 ...]
The following single-character options are accepted:
With arguments: -M -j
Boolean (without arguments): -h -v -V -I -g -G -C -A -D -O -l -L -a -r -p -P -J -w -x -X -T -c -f -i -m -s -t -u
Options may be merged together. -- stops processing of options.
Space is not required between options and their arguments.
For more details run
perldoc -F /usr/bin/cpan
[Now continuing due to backward compatibility and excessive paranoia.
See 'perldoc Getopt::Std' about $Getopt::Std::STANDARD_HELP_VERSION.]
Nothing to install!
kenny@LT-NYC123:~$ perldoc -F /usr/bin/cpan
You need to install the perl-doc package to use this program.
kenny@LT-NYC123:~$ man cpan
kenny@LT-NYC123:~$ sudo cpan App::cpanminus
Loading internal null logger. Install Log::Log4perl for logging messages
Reading '/home/kenny/.cpan/Metadata'
Database was generated on Fri, 19 Oct 2018 15:17:03 GMT
Running install for module 'App::cpanminus'
Fetching with HTTP::Tiny:
http://www.cpan.org/authors/id/M/MI/MIYAGAWA/App-cpanminus-1.7044.tar.gz
Fetching with HTTP::Tiny:
http://www.cpan.org/authors/id/M/MI/MIYAGAWA/CHECKSUMS
Checksum for /home/kenny/.cpan/sources/authors/id/M/MI/MIYAGAWA/App-cpanminus-1.7044.tar.gz ok
'YAML' not installed, will not store persistent state
Configuring M/MI/MIYAGAWA/App-cpanminus-1.7044.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for App::cpanminus
Writing MYMETA.yml and MYMETA.json
MIYAGAWA/App-cpanminus-1.7044.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for M/MI/MIYAGAWA/App-cpanminus-1.7044.tar.gz
MIYAGAWA/App-cpanminus-1.7044.tar.gz
make -- NOT OK
No such file or directory
kenny@LT-NYC123:~$ sudo cpanm --uninstall Crypt::HSXKPasswd
sudo: cpanm: command not found
kenny@LT-NYC123:~$ sudo apt install liblocal-lib-perl cpanminus build-essential
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package liblocal-lib-perl
E: Unable to locate package cpanminus
kenny@LT-NYC123:~$ sudo lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic |
More attempts to get the module working: kenny@LT-NYC123:~$ perl -MConfig -e'CORE::say $INC{"Config.pm"}'
/usr/lib/x86_64-linux-gnu/perl/5.26/Config.pm
kenny@LT-NYC123:~$ vim /usr/lib/x86_64-linux-gnu/perl/5.26/Config.pm
kenny@LT-NYC123:~$ sudo vim /usr/lib/x86_64-linux-gnu/perl/5.26/Config.pm
kenny@LT-NYC123:~$ sudo cpan Crypt::HXSKPasswd
Loading internal null logger. Install Log::Log4perl for logging messages
Reading '/home/kenny/.cpan/Metadata'
Database was generated on Fri, 19 Oct 2018 15:17:03 GMT
kenny@LT-NYC123:~$ hsxkpasswd
hsxkpasswd: command not found
kenny@LT-NYC123:~$ sudo cpan App::cpanminus
Loading internal null logger. Install Log::Log4perl for logging messages
Reading '/home/kenny/.cpan/Metadata'
Database was generated on Fri, 19 Oct 2018 15:17:03 GMT
Running install for module 'App::cpanminus'
Checksum for /home/kenny/.cpan/sources/authors/id/M/MI/MIYAGAWA/App-cpanminus-1.7044.tar.gz ok
'YAML' not installed, will not store persistent state
Configuring M/MI/MIYAGAWA/App-cpanminus-1.7044.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for App::cpanminus
Writing MYMETA.yml and MYMETA.json
MIYAGAWA/App-cpanminus-1.7044.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for M/MI/MIYAGAWA/App-cpanminus-1.7044.tar.gz
MIYAGAWA/App-cpanminus-1.7044.tar.gz
make -- NOT OK
No such file or directory
kenny@LT-NYC123:~$ sudo cpanm --help
sudo: cpanm: command not found |
Installing Perl modules is an essential part of working with Perl. Rather than get into an in-depth explanation of using
cpan
orcpanm
along withlocal::lib
, I'll just break it down into the simplest way possible, manual installation.In short, Perl modules cannot be installed because, for some reason, the files aren't really there even though I can browse, view, edit, delete, etc. those files.
The text was updated successfully, but these errors were encountered: