2

I started today getting a problem with visual studio code and powershell running perl scripts.

After some debugging I found that I can not get the full path of the libraries anymore. For some reason powershell in visual studio code is returning the paths without the disk letter.

I made this script files to test it:

test.pm

package  Utils::test;
use strict;
use File::Basename;

use Exporter 'import'; 
our @EXPORT_OK = qw(test); 

sub test{
    print(__FILE__."\n");
}

1;

test.pl

use strict;
use File::Basename;
use Utils::test;

Utils::test->test()

In PowerShell:

enter image description here

In windows cmd:

enter image description here

In visual studio code power shell:

enter image description here

Both PS instances return the same versions:

Version
-------
5.1.19041.1320

I'm not sure if there was an update in Visual Studio Code since this started happening but it is right now in 1.65.0.

I have no idea if this is an issue with powershell, perl or visual studio code.

Update: From the comments, it seems that there is a linux shell in my windows PS: enter image description here

Update2: Thanks again to @ikegami it seems there are two different perls installed: enter image description here

nck
  • 1,673
  • 16
  • 40

2 Answers2

3

__FILE__ has always been the path used to open the file.

$ cat a.pl
CORE::say __FILE__;

$ perl a.pl
a.pl

$ perl ./a.pl
./a.pl

$ perl ././././a.pl
././././a.pl

$ perl ~/tmp/a/a.pl
/home/ikegami/tmp/a/a.pl

(Linux used here, but it's the same on Windows.)

If you want an absolute path, you can use

use Cwd qw( abs_path );

abs_path( __FILE__ )
ikegami
  • 367,544
  • 15
  • 269
  • 518
  • Thank you for your answer, I change to use abs_path, although in all scenarios the scripts where called from the same folder,but in visual studio I still get a "linux like" path. For example `/c/LocalWorkspace...` instead of `C:\LocalWorkspace...` – nck Mar 07 '22 at 23:11
  • 1
    `Foo::Bar` gets translated to `Foo/Bar.pm`. Always been that way. Windows has always accepted both `/` and `\ ` as dir separators (and same goes for DOS before it), so that's fine. – ikegami Mar 07 '22 at 23:18
  • But my problem comes from getting the absolute path `C:\ ` replaced by the unix `/c/` in visual studio. I have the perl5lib set with `setx PERL5LIB C:\LocalWorkspace\XXXXX\lib\` to store my libraries but for some reason the output in the powershell of visual studio differs from the powershell of my windows. – nck Mar 07 '22 at 23:23
  • 1
    What? There's no `/c/` in the screenshots you posted. Do you mean `abs_path` is resulting in that? If so, you're not using Windows. Maybe you're using a unix emulation environment like Cygwin or MSYS? I think the latter mounts C: as `/c`. Of course `/` is used in unix. – ikegami Mar 07 '22 at 23:30
  • I have a unix subsystem installed with debian, but It shuld not interfere with the powershell in visual studio, I have had that for months and never had this issue. And as you can see in the new screenshot I have added it should be everything windows powershell with normal windows paths. (I used your `abs_path` suggestion for `test.pl` in this scenario.) – nck Mar 07 '22 at 23:42
  • 1
    Re "*It shuld not interfere with the powershell in visual studio*", Correct. It's not likely to be a `perl` from a WSL box. It's possible, but not likely. – ikegami Mar 07 '22 at 23:49
  • 1
    Again, that could only happen in a unix system. Since your screenshot shows that you have a MSYS build of Perl installed on your system (as part of "Git Bash"), I'm going to bet that's the `perl` you're using to get that output. – ikegami Mar 07 '22 at 23:50
  • Wow thanks a lot you are completly right, I have two different perls. I'm not sure how has that landed into de PS of visual studio. I have manually installed strawberry, But maybe as a dependency of some python library that got automatically installed? – nck Mar 07 '22 at 23:59
1

Thanks to the hints of @ikegami I have been able to track back what the issue was. There was another version of perl running in a MSYS which seems to be from git as $Env:Path showed.

So after checking here I saw that the property Terminal Default Profile was set to null, so I changed to powershell and it overtook the MS path and after a restart everything started to work again as expected.

enter image description here

An update on this. I found the reason why this happens. I was starting code from gitbash with code .. When you do this the path gets changed to:

C:\Program Files\Git\usr\bin\vendor_perl;C:\Program Files\Git\usr\bin\core_perl
nck
  • 1,673
  • 16
  • 40