[BUG] cloc won't work if ran through a symlink on Windows (ex Winget) : Can't locate PAR.pm in @INC

[EDM115]

Describe the bug
When I tried to install cloc through winget, every command I run (even cloc --version) fails with the message : Can't locate PAR.pm in @INC (you may need to install the PAR module) (@INC contains:) at -e line 592.. Note that Strawberry Perl is installed

cloc; OS; OS version

• cloc version: winget installed 2.00, i tried replacing the .exe on %LOCALAPPDATA%\Microsoft\WinGet\Packages\AlDanial.Cloc_Microsoft.Winget.Source_8wekyb3d8bbwe with 2.02 from the releases tab but nothing changed
• If running the cloc source, Perl version: v5.40.0
• OS (eg Linux, Windows, macOS, etc): Windows 11
• OS version: 23H2 build 22635.4076

To Reproduce
Install through winget. Note that the npm package works just fine.

Expected result
cloc should work out of the box without any extra step

Additional context
I tried to install manually PAR and PAR::Packer for Perl, without any success. Restarting didn't changed a thing either

[AlDanial]

I don't control the winget package for cloc but the config at https://github.com/microsoft/winget-pkgs/blob/master/manifests/a/AlDanial/Cloc/2.00/AlDanial.Cloc.installer.yaml looks fine.

If you manually download the 2.00 exe from https://github.com/AlDanial/cloc/releases/download/v2.00/cloc-2.00.exe does that work properly for you?

(The 2.02 release is also out; can get it from https://github.com/AlDanial/cloc/releases )

[EDM115]

well. downloading and running from the file works :

the issue seems really to be from winget. here's what happens when I try to run it :

the folder %LOCALAPPDATA%\Microsoft\WinGet\Links\ only contains a symlink to the install folder. I tried replacing the exe on this directory with the one downloaded from the releases tab but the same issue occurs.
interestingly, double clicking on the symlink gives a message for 1/60th of a second :

[EDM115]

Update : the issue comes from the symlink :

[EDM115]

recreating a symlink with New-Item -ItemType SymbolicLink -Path "%LOCALAPPDATA%\Microsoft\WinGet\Links\cloc.exe" -Target "C:\Users\EDM115\AppData\Local\Microsoft\WinGet\Packages\AlDanial.Cloc_Microsoft.Winget.Source_8wekyb3d8bbwe\cloc.exe" gives reproducibly the same outcome

also :

so ultimately I think that cloc can never be ran through a symlink

[AlDanial]

Thanks for investigating the issue. However I'm wondering if the problem is associated with your environment rather than with cloc or its winget package? I did the installation myself, and cloc ran fine:

PS C:\Users\al> winget install AlDanial.Cloc

then opened a new PowerShell terminal and got the version number cleanly:

PS C:\Users\al> cloc --version
2.00

Code counts work properly too. Do you have access to other Windows machines on which to try this?

[danijam]

I've just tried use cloc for the first time and opted to winget install AlDanial.Cloc and am facing this same error.

[AlDanial]

Next thought: a Windows version issue? I'm running Windows 11 Home version 23H2. @danijam , @EDM115 : what versions do you use?

[EDM115]

23H2 too as stated in the original message
I don't have other machines but asked several friends to test this, awaiting their results now

[Dragon1573]

Reproduced. Really weird with this error 😕

Console Logs in a single shell session

17:03:30 C:\...\CMake 2ms pwsh> sudo { winget install -e AlDanial.Cloc -l C:\Applications\AlDanial\Cloc\ --scope machine }
已找到 cloc [AlDanial.Cloc] 版本 2.02
此应用程序由其所有者授权给你。
Microsoft 对第三方程序包概不负责，也不向第三方程序包授予任何许可证。
正在下载 https://github.com/AlDanial/cloc/releases/download/v2.02/cloc-2.02.exe
  ██████████████████████████████  9.43 MB / 9.43 MB
已成功验证安装程序哈希
正在启动程序包安装...
添加了命令行别名： "cloc"
已成功安装

17:04:53 C:\...\CMake 12.47s pwsh> cloc .
Can't locate PAR.pm in @INC (you may need to install the PAR module) (@INC contains:) at -e line 592.

17:05:02 C:\...\CMake 153ms 0x00FF pwsh> winget --info
Windows 程序包管理器(预览) v1.9.2151-preview
版权所有 (C) Microsoft Corporation。保留所有权利。

Windows: Windows.Desktop v10.0.22631.4037
系统体系结构: X64
软件包: Microsoft.DesktopAppInstaller v1.24.2151.0

Winget 目录
-------------------------------------------------------------------------------------------------------------------
日志                   %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
用户设置               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
可移植链接目录(用户)   %LOCALAPPDATA%\Microsoft\WinGet\Links
可移植链接目录(计算机) C:\Program Files\WinGet\Links
可移植包根目录(用户)   %LOCALAPPDATA%\Microsoft\WinGet\Packages
可移植包根目录         C:\Program Files\WinGet\Packages
可移植包根目录 (x86)   C:\Program Files (x86)\WinGet\Packages
安装程序下载           D:\Download

链接
----------------------------------------------------------------------------
隐私声明             https://aka.ms/winget-privacy
许可协议             https://aka.ms/winget-license
第三方声明           https://aka.ms/winget-3rdPartyNotice
主页                 https://aka.ms/winget
Windows 应用商店条款 https://www.microsoft.com/en-us/storedocs/terms-of-sale

管理员设置                                状态
------------------------------------------------
LocalManifestFiles                        已启用
BypassCertificatePinningForMicrosoftStore 已禁用
InstallerHashOverride                     已禁用
LocalArchiveMalwareScanOverride           已启用
ProxyCommandLineOptions                   已禁用
DefaultProxy                              已禁用

17:07:17 C:\...\CMake 1ms pwsh> cd C:\Applications\AlDanial\Cloc\

17:07:37 C:\...\Cloc 10ms pwsh> ls

    Directory: C:\Applications\AlDanial\Cloc

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           2024/8/24    17:04        9891251 cloc.exe

17:07:38 C:\...\Cloc 4ms pwsh> .\cloc.exe C:\Repository\CMake\
      80 text files.
      49 unique files.
      67 files ignored.

github.com/AlDanial/cloc v 2.02  T=0.27 s (180.5 files/s, 25006.9 lines/s)
------------------------------------------------------------------------------------
Language                          files          blank        comment           code
------------------------------------------------------------------------------------
JSON                                 18              0              0           2666
XML                                  16             24              0           1296
C++                                   2            151             62            707
C                                     2            157             61            701
Text                                  3             59              0            277
YAML                                  1             33              0            255
CMake                                 6             48             11            213
Visual Studio Solution                1              1              1             65
------------------------------------------------------------------------------------
SUM:                                 49            473            135           6180
------------------------------------------------------------------------------------

17:08:03 C:\...\Cloc 13.387s pwsh> cloc.exe C:\Repository\CMake\
Can't locate PAR.pm in @INC (you may need to install the PAR module) (@INC contains:) at -e line 592.

Reinstall v2.00

17:26:56 C:\Repository 942ms pwsh> sudo { winget.exe uninstall --purge -e AlDanial.Cloc }
已找到 cloc [AlDanial.Cloc]
正在启动程序包卸载...
已成功卸载

17:28:44 C:\Repository 4.783s pwsh> sudo { winget install -e AlDanial.Cloc -l C:\Applications\AlDanial\Cloc\ --scope machine -v 2.00 }
已找到 cloc [AlDanial.Cloc] 版本 2.00
此应用程序由其所有者授权给你。
Microsoft 对第三方程序包概不负责，也不向第三方程序包授予任何许可证。
正在下载 https://github.com/AlDanial/cloc/releases/download/v2.00/cloc-2.00.exe
  ██████████████████████████████  9.30 MB / 9.30 MB
已成功验证安装程序哈希
正在启动程序包安装...
添加了命令行别名： "cloc"
已成功安装

17:29:33 C:\Repository 12.757s pwsh> cloc --version
Can't locate PAR.pm in @INC (you may need to install the PAR module) (@INC contains:) at -e line 592.

Launch a brand new shell session

**********************************************************************
** Visual Studio 2022 Developer PowerShell v17.11.0-pre.5.0
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************

17:31:57 C:\Repository 1.454s pwsh> cloc --version
Can't locate PAR.pm in @INC (you may need to install the PAR module) (@INC contains:) at -e line 592.

[Dragon1573]

There's something happened. Outputs from 2 methods are different.

17:39:57 C:\Repository 8ms pwsh> cloc
Usage: C:\Program Files\WinGet\Links\cloc.exe [ -Alib.par ] [ -Idir ] [ -Mmodule ] [ src.par ] [ program.pl ]
C:\Program Files\WinGet\Links\cloc.exe [ -B|-b ] [-Ooutfile] src.par

17:41:37 C:\Repository 57ms 0x00FF pwsh> C:\Applications\AlDanial\Cloc\cloc.exe

                       cloc -- Count Lines of Code

Usage:
    cloc.exe [options] <file(s)/dir(s)/git hash(es)>
        Count physical lines of source code and comments in the given files
        (may be archives such as compressed tarballs or zip files) and/or
        recursively below the given directories or git commit hashes.
        Example:    cloc src/ include/ main.c

    cloc.exe [options] --diff <set1>  <set2>
        Compute differences of physical lines of source code and comments
        between any pairwise combination of directory names, archive
        files or git commit hashes.
        Example:    cloc --diff Python-3.5.tar.xz python-3.6/

cloc.exe --help  shows full documentation on the options.
https://github.com/AlDanial/cloc has numerous examples and more information.

17:45:27 C:\Repository 2ms pwsh> ls 'C:\Program Files\WinGet\Links\cloc.exe'

    Directory: C:\Program Files\WinGet\Links

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
la---           2024/8/24    17:35              0 cloc.exe -> C:\Applications\AlDanial\Cloc\cloc.exe

[EDM115]

just booted up a fresh VM, and the issue occurs in the exact same way

[AlDanial]

@EDM115 : I should have read your initial post more closely, re the OS version, thanks for the reminder.

@Dragon1573 : is there a way to write the winget manifest for cloc without using a symlink?

[Dragon1573]

Is there a way to write the winget manifest for cloc without using a symlink?

This is the designed feature of winget.exe. All portable executable uses symlink for launching in the console.

Maybe it's caused by pp command? Can perl2exe solve this?

Or create an install wizard (by InnoSetup, NullSoft, Burn, WiX, ...) for cloc? winget.exe will just launch the wizard with "silent install" switches. The wizard itself will handle everything, including creating shortcuts, writing Windows Registry, uninstall previous versions.

[EDM115]

@AlDanial @Dragon1573 @danijam I think I fixed it, will open a PR

[AlDanial]

This should be 100% resolved now; the latest winget package points to the 2.02 executable which includes @EDM115 's PR #850.

[danijam]

I can still reproduce. How can I check that I'm not somehow still pulling an outdated winget package?

[EDM115]

@danijam I guess there was maybe an issue when rebuilding https://github.com/AlDanial/cloc/releases/download/v2.02/cloc-2.02-winget.exe
I provided a working executable here : #850 (comment), and feel free to build it yourself if you don't trust random files on the internet :)

[AlDanial]

I'm baffled since PR #850 is in the source I used to build cloc-2.02-winget.exe. Since I never had a problem with symlinks in the first place I have no way of checking that cloc-2.02-winget.exe behaves differently from the original cloc-2.02.exe. For the same reason, @EDM115, I gain nothing from testing your executable.

[EDM115]

hmmm…
A possible reason why you never encountered the problem may be because cloc is installed through another way and this installation path is higher in the PATH variables so it takes priority over the WinGet one… tho at this point it's pure speculation. Maybe we're just unlucky with WinGet after all :(

[AlDanial]

Good thinking, I hadn't tested that til now. I used the output of where cloc to get the full path to the winget-installed cloc.exe, entered that full command, and got the same successful result.

[mr-mihu]

I don't know where to report this issue, and I hope to get some help.

It seems that the win username in the environment variables is garbled in Chinese

[EDM115]

@mr-mihu maybe this is more likely a winget issue ?

[glektarssza]

Wanted to chime in that I have found a (very hacky and temporary) work around.

(Get-Item $env:LOCALAPPDATA\Microsoft\WinGet\Links\cloc.exe).Delete(); New-Item -Type HardLink -Path $env:LOCALAPPDATA\Microsoft\WinGet\Links\cloc.exe -Target $env:LOCALAPPDATA\Microsoft\WinGet\Packages\AlDanial.Cloc_Microsoft.Winget.Source_8wekyb3d8bbwe\cloc.exe;

I really don't advise doing this, personally, but it does work.

It's something specific to symbolic links, obviously.

[EDM115]

@glektarssza once again you can also copy-paste the built file from #850 (comment) and the symlink will work flawlessly

[EDM115]

edit : I built the latest cloc (ccb88c0) since it have the same issues :(
#850 (comment)

[AlDanial]

@EDM115 are your build steps different than the ones I have at https://github.com/AlDanial/cloc?tab=readme-ov-file#building-a-windows-executable- ?

[EDM115]

absolutely not, and that's what puzzles me :(
I know nothing about Perl so when I tried to fix the issue I followed the instructions you provided
as said in my comment the only difference is that newest Strawberry Perl versions invalidate one test of Win32::LongPath so we must skip them (cc rdboisvert/Win32-LongPath#14 and maybe rdboisvert/Win32-LongPath#13, hence the combo cpan -if Win32::LongPath/cpanm --notest Win32::LongPath that I used to install this dependency)
apart from that the build steps are the exact same.
all I can say is that I'm building it on Windows, which is probably what you do anyway

[EDM115]

hmmm so I checked a bit further the repo and noticed that you probably create releases by hand.
a potential solution I'm thinking about is to automate the process through GitHub Actions.

as far as I can see releases contains :

• built Windows executable (see under)
• probably the cloc at repo root renamed with an extension
• a targz of the code
• the readme
• release notes. automating this could be painful tbh, but I believe a solution would be to take the notes of the previous release, appending the new ones (for example coming from the body of a pull request with a certain tag like "release-staging"), and an action picks up PRs with this tag and start to work

since windows is the only distro to have a built executable we could run the action on windows-latest, and it would serve as a blank canvas without any prior installed software
as said here there's no preinstalled packages on windows but chocolatey is available so we could use choco install strawberryperl to get it started

once the exe built we could probably automate the virustotal scan (they must have APIs) and add it to the readme as you do.
it would then go to a commit in the PR branch, the executable added as a file there, tags updated (removed "release-staging" and adds "release-ready" or something similar)
Once the "release" PR is merged another action picks up (on ubuntu since it's less pricey), using something like softprops/action-gh-release, takes all the necessary files (built exe, updated readme) and creates a release with them and the PR body as release notes

---

i'm probably overcomplicating the entire process but it could be a solution.
however if you envision it as the way forward, tell me so I can test these things on my end and give feedback about whether the action built exe solves this issue at all

[AlDanial]

True, I'm creating releases by hand. At a rate of two per year it isn't a big deal. I agree 100% though that setting up the Windows exe build with Github Actions is the way to go. I'll create a new issue to do that, cross link to this one. Will take some effort to learn about how to make Github Actions stuff gowrk.

[EDM115]

alright :)
i'm testing the build process on my side and especially want to see if the exe solves this issue at all
there's several issues that i need to fix on the actions and having to reopen a PR and wait for the absurdly long package installs to happen doesn't help :(

so far I've seen an issue with pp saying that declared_refs needs to be enabled where it should not (?)
so i'm trying to get latest strawberry perl to see if that's just due to its preinstalled version being 4 years old

edit: installing an older version of PAR::Packer seems really hard and fails whatever the method is.
i'm out of ideas, will check back tommorrow

[EDM115]

update : i've been able to successfully build the exe (and it is confirmed to work in the context of this issue, so perfect for winget), automate the VirusTotal analysis and automate file changes too
so far I only have to fix several small issues but it's looking good !

the problems of yesterday were just skill issues on my end