search

rschupp / PAR-Packer

(perl) Generate stand-alone executables, perl scripts and PAR files https://metacpan.org/pod/PAR::Packer
Other
48 stars 13 forks source link

Symlinks not working on Windows #48

Closed kal247 closed 3 years ago

kal247 commented 3 years ago

Hello,

I'm not able to use symbolic link(s) to call the packed script(s), on Windows 10 and Server 2016.

Please see this link for example code and details : https://perlmonks.org/?node_id=11134716

If it's not supported, I'd suggest to document it (maybe also the fact that macOS aliases and Windows shortcuts won't work, it's not necessarily obvious for everyone).

Thanks

rschupp commented 3 years ago

if it's not supported, I'd suggest to document it (maybe also the fact that macOS aliases and Windows shortcuts won't work, it's not necessarily obvious for everyone).

Where does it say that it should work?

kal247 commented 3 years ago

Here :

when multiple programs are packaged, the produced executable will run the one that has the same basename as $0 (i.e. the filename used to invoke it).

Plus, on Linux and macOS, any Perl script called through a symlink has $0 = symlink name.

I've now made some additional tests on Windows, and a process invoked through a symlink gets the executable name, so I suppose that perl doesn't even get the symlink, is it correct?

AlDanial commented 18 hours ago

Ref https://github.com/AlDanial/cloc/issues/849, PAR-Packer's issue with symlinks on Windows causes problems for Perl executables installed via winget.

Dragon1573 commented 11 hours ago

Ref AlDanial/cloc#849, PAR-Packer's issue with symlinks on Windows causes problems for Perl executables installed via winget.

For any portable executable, winget.exe will create a symbolic link for that executable in specific folders (mostly %LOCALAPPDATA%\Microsoft\WinGet\Links and C:\Program Files\WinGet\Links), and add them into $PATH environment variables. This mechanism is how winget.exe is designed to be.