I have installed perlbrew and installed two Perls with it.
Now I am trying to separate libraries for modules I install with cpanm.
I want (if possible) to switch to one Perl (within Perlbrew) (for example: 5.22.4) and once I call cpanm install Some::Module the module will be installed in the separate library, related only to this Perl.
Then, in the script, I would like to have like the example below:
#!/usr/bin/env perl
use strict;
use Some::Module;
print "Content-type:text/html\n\n";
print "Works!";
and that's it. No any other use lib 'path'; or so.
I tried to use perlbrew lib create perl-5.22.4#somename and then switch to it.
Then call cpanm install Some::Module and I see the result at the location ~/.perlbrew/perl-5.22.4#somename/lib/perl5/Some/Module.pm, but when I call my script from a browser I see Error 500 and the logs say "missing module Some::Module, check #INC etc..."
What I also found that if I move the ~/.perlbrew/perl-5.22.4#somename/lib/perl5/Some/Module.pm to ~/perl5/perlbrew/perls/perl-5.22.4/lib/5.22.4/Some/Module.pm or to /home/arseniigorkin/perl5/perlbrew/perls/perl-5.22.4/lib/site_perl/5.22.4/x86_64-linux/Some/Module.pm then the script works. And Perl 5.22.4 (in our example) has its own library without need to use use lib 'path';
But, how to set up Perlbrew to switch cpanm automatically to this directory?
What I was also trying: cpanm install -l /home/arseniigorkin/perl5/perlbrew/perls/perl-5.22.4/lib/site_perl/5.22.4/x86_64-linux Some::Module to specify the target lib dir, but it creates the next tree under /home/arseniigorkin/perl5/perlbrew/perls/perl-5.22.4/lib/site_perl/5.22.4/x86_64-linux instead:
lib
perl5
Some
Module.pm
x86_64-linux
auto
[.....]
.meta
[.....]
perllocal.pod
install.pm
man
man3
[.....]
and, sadly, the script throws Error 500.
So, is there a possibility to omit use lib 'path'; in the script, switching between multiple Perl versions in Perlbrew?
This all happens on Ubuntu 22.04.
Update:
When switching to perl-5.22.4#somename and installing Some::Module via cpanm the module appears under the ~/.perlbrew/perl-5.22.4#somename/lib/perl5/Some/Module.pm as mentioned above, but the CGI script fails with Error 500.
However, when I execute the next command: perlbrew list-modules it shows Some::Module as installed under the current Perl (which I am switched to). So, this is a dissonance: Perlbrew "sees" the module under the specific Perl, but the CGI script cannot "see" this module under the same Perl.
Update 2:
here is the output of the perlbrew info:
Current perl:
Name: perl-5.22.4#somename
Path: /home/username/perl5/perlbrew/perls/perl-5.22.4/bin/perl
Config: -de -Dprefix=/home/username/perl5/perlbrew/perls/perl-5.22.4 -Dusesitecustomize -Aeval:scriptdir=/home/username/perl5/perlbrew/perls/perl-5.22.4/bin
Compiled at: Nov 10 2022 23:26:53
perlbrew:
version: 0.96
ENV:
PERLBREW_ROOT: /home/username/perl5/perlbrew
PERLBREW_HOME: /home/username/.perlbrew
PERLBREW_PATH: /home/username/.perlbrew/libs/perl-5.22.4#somename/bin:/home/username/perl5/perlbrew/bin:/home/arseniigorkin/perl5/perlbrew/perls/perl-5.22.4/bin
PERLBREW_MANPATH: /home/username/.perlbrew/libs/perl-5.22.4#somename/man:/home/username/perl5/perlbrew/perls/perl-5.22.4/man
Update 3:
The dirs permissions for the libs:
and
#terry0its is the name of the library (in the example I called it #somename.
Update 4:
Printing vars:
PERL_MB_OPT
PERL_MM_OPT
PERL5LIB
PATH
PERL_LOCAL_LIB_ROOT
with the script:
#!/usr/bin/env perl
print "Content-type:text/html\n\n";
print <<HTML;
Vars:<br>
PERL_MB_OPT = #{[$ENV{"PERL_MB_OPT"}]}<br>
PERL_MM_OPT = #{[$ENV{"PERL_MM_OPT"}]}<br>
PERL5LIB = #{[$ENV{"PERL5LIB"}]}<br>
PATH = #{[$ENV{"PATH"}]}<br>
PERL_LOCAL_LIB_ROOT = #{[$ENV{"PERL_LOCAL_LIB_ROOT"}]}<br>
HTML
In the web browser:
Vars:
PERL_MB_OPT =
PERL_MM_OPT =
PERL5LIB =
PATH = /home/username/.perlbrew/libs/perl-5.22.4#terry0its/bin:/home/username/perl5/perlbrew/bin:/home/username/perl5/perlbrew/perls/perl-5.22.4/bin:/root/Komodo IDE/bin:/home/username/anaconda3/condabin:/root/Komodo IDE/bin:/home/username/pycharm/bin:/home/username/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/home/username/.local/share/JetBrains/Toolbox/scripts
PERL_LOCAL_LIB_ROOT =
With the terminal:
Content-type:text/html
Vars:
PERL_MB_OPT = --install_base
/home/username/.perlbrew/libs/perl-5.22.4#terry0its
PERL_MM_OPT =
INSTALL_BASE=/home/username/.perlbrew/libs/perl-5.22.4#terry0its
PERL5LIB =
/home/username/.perlbrew/libs/perl-5.22.4#terry0its/lib/perl5
PATH =
/home/username/.perlbrew/libs/perl-5.22.4#terry0its/bin:/home/username/perl5/perlbrew/bin:/home/username/perl5/perlbrew/perls/perl-5.22.4/bin:/root/Komodo
IDE/bin:/home/username/anaconda3/condabin:/root/Komodo
IDE/bin:/home/username/pycharm/bin:/home/username/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/home/username/.local/share/JetBrains/Toolbox/scripts
PERL_LOCAL_LIB_ROOT =
/home/username/.perlbrew/libs/perl-5.22.4#terry0its
Update 5:
When I switch to a pure perl-5.22.4 (without external lib, like #terry0its) I see the next output for the same scripts (after the restart of the server):
In the web browser:
Vars:
PERL_MB_OPT =
PERL_MM_OPT =
PERL5LIB =
PATH = /home/username/anaconda3/condabin:/home/username/perl5/perlbrew/bin:/home/username/perl5/perlbrew/perls/perl-5.22.4/bin:/root/Komodo IDE/bin:/home/arseniigorkin/perl5/bin:/home/username/pycharm/bin:/home/username/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/home/username/.local/share/JetBrains/Toolbox/scripts
PERL_LOCAL_LIB_ROOT =
With the terminal:
Content-type:text/html
Vars:
PERL_MB_OPT --install_base "/home/username/perl5"
PERL_MM_OPT = INSTALL_BASE=/home/username/perl5
PERL5LIB =
PATH =
/home/username/anaconda3/condabin:/home/username/perl5/perlbrew/bin:/home/username/perl5/perlbrew/perls/perl-5.22.4/bin:/root/Komodo IDE/bin:/home/username/perl5/bin:/home/username/pycharm/bin:/home/username/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/home/username/.local/share/JetBrains/Toolbox/scripts
PERL_LOCAL_LIB_ROOT =
/home/username/perl5
The issue was related to Apache2 server-specific behavior with ENV variables.
It strips off some environment variables so they are undefined in your CGI scripts.
To have them in the CGI script you simply have to add PassEnv PERL5LIB into your host conf file and restart the server. Then, voila - you have PERL5LIB showing correctly in the output of $ENV{PERL5LIB} all across your site.
The example code:
<Directory "/home/user/someproject/server/www/public_html/cgi-bin">
AllowOverride All
Options None
Require all granted
Options +ExecCGI
PassEnv PERL5LIB
AddHandler cgi-script .cgi .pl
</Directory>
So, to use Perlbrew and easily switching between Perls and to have automatically handling all your libs (incl. externally created with perlbrew create lib somename) you have to PASS the PERl5LIB environment to your CGI scripts explicitly in the Apache configuration file for your host.
Do not forget to check if your mod_env is enabled in the httpd.conf (main Apache configuration file) as LoadModule env_module modules/mod_env.so (it must be uncommented).
I hope it will help others to handle easily their Perl libraries of perlbrew with Apache2 server.
Also, the module mod_env allows us to add custom environment variables, that we will be able to use all across the host or a server (it depends on where you put it in - inside the main conf file, your host file, or just into .htaccess for a particular dir(s) or even page(s)).
perlbrew does two things:
Makes installing Perl a little bit easier.
Manipulate the PATH of a shell that loads it.
The CGI script isn't launched by a shell.
First, you shouldn't be using PERL5LIB. Why install a custom perl using perlbrew and then try to cause it to use modules installed by another perl? This is nothing but bad. Unset PERL5LIB.
And with PERL5LIB unset, you shouldn't be using PERL_MB_OPT and PERL_MM_OPT either. You need to let the modules get installed where perl will find them.
So start by cleaning out the mess. Make sure PERL5LIB, PERL_MB_OPT and PERL_MM_OPT aren't set anywhere. You may to need reinstall the modules if they were installed in a weird place.
Now, using the correct perl will load the modules installed by that perl.
So what left is ensuring that we're using the correct perl. You use /usr/bin/env to locate perl. Does it makes sense for Apache's PATH to control which perl your application uses? Probably not.
What I would do is create an alias in perlbrew for your project.
perlbrew alias create perl-5.22.4#somename myproject
Then use the following shebang line:
#!/home/username/perl5/perlbrew/perls/myproject/bin/perl
That will allow you use to control which build of perl your project uses using
perlbrew alias create -f ... myproject
This works using symlinks, not PATH manipulation, so it works from anywhere, not just shells using perlbrew.
Related
I am using the Dist::Zilla module to release and test my module. I am also using Perlbrew. When I run a script using perlbrew that includes my module, the script runs fine:
use strict;
use My::Module;
However, whenever I run dzil test, on a test that just tries to include my module:
#!perl -T
use strict;
use warnings FATAL => 'all';
use Test::More;
plan tests => 1;
BEGIN {
use_ok( 'My::Module' ) || print "Bail out!\n";
}
diag( "Testing My::Module $My::Module::VERSION, Perl $], $^X" );
It fails with this error saying that it can't find the module Mouse (which my module includes):
Error: Can't locate Mouse.pm in #INC (you may need to install the Mouse module) (#INC contains:
/Users/user/github/My/Module/.build/HoKOnIQGYr/blib/lib
/Users/user/github/My/Module/.build/HoKOnIQGYr/blib/arch
/Users/user/perl5/lib/perl5/darwin-thread-multi-2level
/Users/user/perl5/lib/perl5/darwin-thread-multi-2level
/Users/user/perl5/lib/perl5
/opt/local/lib/perl5/vendor_perl/5.16.1/darwin-thread-multi-2level/
/Users/user/perl5/lib/perl5/darwin-thread-multi-2level
/Users/user/perl5/lib/perl5
/opt/local/lib/perl5/vendor_perl/5.16.1/darwin-thread-multi-2level/
/Library/Perl/5.18/darwin-thread-multi-2level /Library/Perl/5.18
/Network/Library/Perl/5.18/darwin-thread-multi-2level
/Network/Library/Perl/5.18
/Library/Perl/Updates/5.18.2/darwin-thread-multi-2level
/Library/Perl/Updates/5.18.2
/System/Library/Perl/5.18/darwin-thread-multi-2level
/System/Library/Perl/5.18
/System/Library/Perl/Extras/5.18/darwin-thread-multi-2level
/System/Library/Perl/Extras/5.18) at
/Users/user/github/My/Module/.build/HoKOnIQGYr/blib/lib/My/Module.pm line 4.
It says that it cannot find Mouse.pm, which I know is located at
/Users/user/perl5/lib/perl5/darwin-2level
I see that for some reason that directory is not located in #INC, which is interesting because if I run this command to print out all the directories in #INC:
perl -e 'print "$_\n" for #INC'
I get:
/Users/user/perl5/lib/perl5/darwin-2level
/Users/user/perl5/lib/perl5
/opt/local/lib/perl5/vendor_perl/5.16.1/darwin-thread-multi-2level/
/Users/user/perl5/perlbrew/perls/perl-5.16.0/lib/site_perl/5.16.0/darwin-2level
/Users/user/perl5/perlbrew/perls/perl-5.16.0/lib/site_perl/5.16.0
/Users/user/perl5/perlbrew/perls/perl-5.16.0/lib/5.16.0/darwin-2level
/Users/user/perl5/perlbrew/perls/perl-5.16.0/lib/5.16.0
.
So when I run perl on the command line then the darwin-2level directory is present in #INC, but whenever I run dzil test it is not. This might not have much to do with Dist::Zilla, since I think Dist::Zilla just creates Makefile.PL and runs make test for you. Could this be because for testing an older version of perl is being required? Like so:
use 5.006;
But even so, some Perlbrew directories are present in #INC during the test such as
/Users/user/perl5/lib/perl5/darwin-thread-multi-2level
Does anyone know how I can make it so I can use the Mouse installation in my perl directory instead of installing a systemwide one? I had a previous error with another module that couldn't be found when I ran dzil test, and that module was in the same directory as Mouse. I was able to fix the issue by installing the module systemwide instead of locally in my home perl5 directory, but I'd prefer to use the Mouse installed by Perlbrew and not mess with my system perl if possible. I am using Perlbrew version 0.73.
You're trying to install it using the wrong perl since you're using dzil installed by a different perl than the one you want to use.
Furthermore, you shouldn't see any of the following in your perlbrewed perl's #INC:
/Users/user/perl5/lib/perl5/darwin-2level
/Users/user/perl5/lib/perl5
/opt/local/lib/perl5/vendor_perl/5.16.1/darwin-thread-multi-2level/ (You perlbrewed perl isn't even threaded!!!)
Let's clean up your environment.
Unset env vars PERL5LIB, PERLLIB, PERL5OPT, PERL_MM_OPT and PERL_MB_OPT. Permanently. Get rid of them in your login scripts, then unset them from the current shell or log back in. (Make a note of what they were as a backup.)
Clear cpan's configuration item makepl_arg. From within cpan,
o conf makepl_arg # Just to see its current value as a backup.
o conf makepl_arg ''
o conf commit
In particular, we want to remove anything that indicates an installation path, including INSTALL_BASE, PREFIX and LIB.
Clear cpan's configuration item mbuildpl_arg. From within cpan,
o conf mbuildpl_arg # Just to see its current value as a backup.
o conf mbuildpl_arg ''
o conf commit
In particular, we want to remove anything that indicates an installation path, including --install_base, --prefix and --lib.
Since you're there, do the following from within cpan:
o conf build_dir_reuse 0
o conf commit
This will restore the setting to its default, which will save you headaches if it was changed.
Install the dependencies.
cpan Dist::Zilla Mouse
At this point, executing which dzil should give
/Users/user/perl5/perlbrew/perls/perl-5.16.0/bin/dzil
If so, you should be good to go.
If not, do hash -r and try which dzil again. (This shouldn't be needed, but just to be sure.)
If still not, provide the output of the following commands:
echo "$PATH"
which cpan
head -n 3 "$( which cpan )"
echo 'o conf' | cpan | grep arg
which dzil
head -n 3 "$( which dzil )"
perl -V # Uppercase "V"
I am trying to build LDV project by following this instructions, and i know nothing about perl.
i am getting the following error while running the test
ldv-task: NORMAL: Calling LDV-core.
Can't locate SOAP/Lite.pm in #INC (#INC contains: /home/acsia/perl5/perlbrew/perls/perl-5.10.0/lib/5.10.0/x86_64-linux /home/acsia/perl5/perlbrew/perls/perl-5.10.0/lib/5.10.0 /home/acsia/perl5/perlbrew/perls/perl-5.10.0/lib/site_perl/5.10.0/x86_64-linux /home/acsia/perl5/perlbrew/perls/perl-5.10.0/lib/site_perl/5.10.0 .) at /home/acsia/Desktop/LDV/consol-tools/ldv-core/ldv-core line 7.
BEGIN failed--compilation aborted at /home/acsia/Desktop/LDV/consol-tools/ldv-core/ldv-core line 7.
output of
perlbrew use
is :EDITED:
Currently using perl-5.22.0
output of
locate SOAP/Lite.pm
is
/usr/local/lib/perl5/site_perl/5.22.0/SOAP/Lite.pm
output of
which perl
is
/usr/local/bin/perl
and the LDV-core file is starting like this by default
#!/usr/bin/perl -w
#
my $instrumnet = 'ldv-core';
use FindBin;
# To prevent meaningless module warnings use this instead of use.
BEGIN { $SIG{'__WARN__'} = sub{}; require SOAP::Lite; SOAP::Lite->import(); $SIG{__WARN__}='DEFAULT'; }
use POSIX ":sys_wait_h";
use XML::Twig;
use IO::Socket::INET;
#use File::MimeInfo;
use File::Basename;
use Cwd qw(abs_path);
etc,... etc....
Thanks for your time...
If LDV-Core isn't yours, you should install SOAP::Lite using your system's package manager. If it's yours, read on.
perlbrew plays with your PATH so that executing perl will execute the desired perl.
But your script explicitly uses /usr/bin/perl, so which perl is currently selected using perlbrew switch or perlbrew use is irrelevant.
Stop overriding the default install location, and stop looking where you shouldn't.
unset PERL_MM_OPT
unset PERL_MB_OPT
unset PERL5LIB
unset PERLLIB
echo -ne 'o conf makepl_arg ""\no conf commit\n' | cpan
echo -ne 'o conf mbuildpl_arg ""\no conf commit\n' | cpan
The first four lines only have a temporary effect. You should stop setting those variables in your login script to make the change permanent.
Install SOAP::Lite in the desired Perl.
perlbrew use perl-5.22.0 # Or perl-5.10.0 or whatever
cpan SOAP::Lite
Fix your script's shebang.
perl -i~ -pe'
next if $. != 1;
s/^#!.*//s;
$_ = "#!$^X\n$_";
' LDV-core
PS — You don't need use FindBin;.
perlbrew perl is a way to install many perl versions in same machine. It is like virtenv in python. Perlbrew allow you to switch between various versions of perl and run perl programs against those versions.
system perl means the default version of perl which mostly come with linux distros. perlbrew changes that version against which program needs to run and your program will start running against different version.
If you are making something which does not require a lot of perl versions it is always better to use one version of perl and run programs against them.
Also if you are using linux distros and do not want to get into cpan and how to install perl modules, best is to search for corresponding libraries against that module and install them. For example in your case i search this way
aptitude search soap | grep perl
This give me two libraries on my ubuntu machine of which one is against this module. Installing them is easy and you can focus on your work rather than on how to install cpan modules.
I used to delete my ActivePerl once, and all the installed modules were lost. So now I am very careful with this kind of issue. Due to some reason, I want to use Strawberry Perl now, while keeping ActiveState's ActivePerl in use.
Will this cause compatibility issues? Is it advisable?
This will not be a problem as both the Perl implementations will look at different directories for modules. That is, the #INC entries will be different.
I keep both ActivePerl and Strawberry Perl installed on my Windows 7 Pro instance. My PATH variable order decides my Perl preference. E.g, for using ActivePerl I set my PATH to something like this:
C:\Perl64\bin;C:\strawberry\perl\bin
You can always override this in your script using shebang:
#!C:\strawberry\perl\bin\perl
You could use two (many) different Perl versions at once.
Set your PATH variable to include your primary Perl path (path to perl.exe) to be sure that you are running the correct Perl when you start a program with perl script.pl.
You could use Perlbrew (or other modules) to help keeping multiple Perl installations on your computer.
It is available on Windows: http://code.activestate.com/ppm/App-perlbrew/
I found another solution for this. You could embed your Perl code into a Windows batch file. This way you could set environment variables before executing your Perl script or include your module path.
#echo off
cd %TEMP%
set perl_bindir=C:\strawberry\perl\bin
set module_dir=C:\my_perl_modules
set path=%perl_bindir%;%path%
echo Launching %0 perl script
%perl_bindir%\perl.exe -I %module_dir% -x -S %0 %*
goto endofperl
#!perl -w
use strict;
print "Hello World\n";
__END__
:endofperl
Having problems getting CPAN to work with a MiniCPAN repository from within a script (aim is a code deployment system to build local modules together with modules from CPAN, install to a local-lib, and then sync out to servers)
$HOME/.cpan/CPAN/MyConfig.pm exists, with urllist set to ['file:///home/user/minicpan/']
The (non-CPAN) module distribution was injected sucessfully into the minicpan repo, and file exists: e.g. /home/user/minicpan/authors/U/US/USER/My-Module-0.01.tar.gz.
The author is in .../01mailrc.txt.gz, module is in .../modules/02packages.details.txt.gz
The module is found and installs via the cpan shell.
Fails through following code:
CPAN::HandleConfig->load;
CPAN::Shell::setup_output;
CPAN::Index->reload;
# dumping config here shows urllist set correctly,
# and config exactly the same as through shell
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;
print Dumper($CPAN::Config);
CPAN::Shell->install("My::Module");
Either doesn't find module ("Cannot install My::Module, don't know what it is.") or claims is up to date (My::Module is up to date (0.01))
Module is not installed in the local-lib (and not anywhere else on machine, e.g. in /usr/...)
Local-lib environment variables are set via
eval $(perl -I$HOME/foo/lib/perl5 -Mlocal::lib=$HOME/locallib) in bash profile
After getting either error (including 'Module is up to date'), a normal 'install' in the shell works without force, as does perl -MCPAN -e "install My::Module", so I presume it's the config not set correctly, but the CPAN.pm docs are rather hard to follow...
(CPAN.pm is v1.9402)
try :
#!/usr/bin/perl -w
system <cpan install My::Module>
I have Strawberry Perl and have msys Perl 5.6 removed.
Now perl will invoke Strawberry (due to PATH env) but how do I map the perl command in .pl or other Perl script files which have #!/bin/perl or #!/usr/bin/perl shebang lines?
I was thinking of making a hardlink to perl.exe in msys/bin or merge the whole Strawberry inside the msys directory, but I'm not sure.
The solution is to create a symlink to the Strawberry Perl executable from within MSYS Tip of the hat to smaudet for his input:
First, remove or rename the Perl executables that the MSYS installation came with, if any (which the OP has already done); e.g.:
mv /usr/bin/perl /usr/bin/perl.msys
mv /usr/bin/cpan /usr/bin/cpan.msys
Then create a symlink to Strawberry Perl's executable in its place:
ln -s /c/strawberry/perl/bin/perl.exe /usr/bin/perl
# Unfortunately, doing the same for `cpan` doesn't work directly, because
# Strawberry Perl's `cpan` executable is a *batch* file, `cpan.bat`, which
# cannot be directly invoked from MSYS.
# To invoke it from MSYS (assuming it is in the %PATH%):
# cmd /c 'cpan.bat ...'
# With an explicit path:
# cmd /c 'c:\strawberry\perl\bin\cpan.bat ...'
#
# Here's how to create a stub script that still allows invocation as
# `cpan`:
echo 'cmd /c "C:\strawberry\perl\bin\cpan.bat $*"'>/usr/bin/cpan && chmod +x /usr/bin/cpan
Once the /usr/bin/perl symlink is in place, existing scripts with shebang lines #!/usr/bin/perl and #!/bin/perl will work again (the latter also works, because /bin and /usr/bin are effectively the same location in MSYS).
Note that scripts written with the more flexible shebang line #!/usr/bin/env perl do not need this, because env will directly find Strawberry Perl's perl.exe in the path.
Some background:
Unix-emulation environments such as MSYS and Cygwin do not respect Windows' %PATHEXT% variable to determine what executable to invoke a (non-binary) file with. In other words: filename extensions have no meaning with respect to execution there.
Instead, they solely go by whether the file has a shebang line:
If there is one, the executable specified in the shebang line is used.
If there is none, the default (POSIX-like) shell /bin/sh is used.
Thus, trying to invoke *.bat or *.cmd files directly fails, because they don't have a Unix shebang line and are therefore executed by /bin/sh rather than cmd.exe.
Unlike in Windows, this also works with (executable) files that have no filename extension at all.
this works beautifully on the windows side of the computer, on the MSYS side you may need to
check the PATH environment variable and fix to include the strawberry perl access path
check the scripts for complete path in the shebang line (#!/usr/bin/perl).
Those paths that are absolute in msys are in fact relative to the msys install directory in windows.
you may need to "plug" your strawberry perl install to match or change the #! line
in the latter case my recommendation would be to use something like: #!env perl that checks the environment for the perl interpreter and alleviate the burden of dealing with /cygdrive/c/my/windows/path/not/visible/from/msys/otherwise
The correct shebang would be, eg. #!"C:/strawberry/perl/bin/perl.exe". However, you might prefer to run scripts explicitly with Perl rather than rely on the shebang, eg. perl script.pl or perl "C:\strawberry\perl\bin\cpan"
Note that Strawberry Perl doesn't get the shebang right for its own scripts, such as cpan and perldoc . Bug reported at https://rt.cpan.org/Public/Bug/Display.html?id=82837