Re: PAR::Filter::Crypto Fails

Just a guess: it's irritating me that you mix win and *nix path delimiters.

like ... 296\inc\lib/Filter/Crypto/...

This might be OK on a win file-system (they don't escape with backslash) but a pure Perl loader might get confused trying to find "escaped characters" in its packaged cache.

Maybe try switching to pure *nix paths notation and see the packer still has problems?

Cheers Rolf
_{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)

Wikisyntax for the Monastery}

Comment on Re: PAR::Filter::Crypto Fails Download Code

Replies are listed 'Best First'.
Re^2: PAR::Filter::Crypto Fails by hv (Prior) on Apr 25, 2023 at 23:49 UTC
It isn't clear to me what you are suggesting the OP could do differently here - the mixed path delimiters appear in the error messages shown, but the program and command used don't appear to introduce any of those delimiters explicitly. So while you may have identified a symptom of an underlying bug somewhere, it isn't clear to me that you have identified an error in what the OP is doing, or any course of action for them to follow. But perhaps I misunderstand the intent of your comment.	[reply]
Re^3: PAR::Filter::Crypto Fails by LanX (Saint) on Apr 26, 2023 at 09:02 UTC
@INC - even on windows - should have `/` as delimiter PAR is using an INC hook to load modules from memory the INC-hook will load those modules based on a hash look-up if backslashes are used in the string representations of paths they are interpreted as escapes > what you are suggesting the OP could do differently here check @INC again check if the same problem is also happening on linux if that fails file a bug report with the crypt module Anyway, while this was my intent, it seems like swl already identified the problem in the meantime: --> Re: PAR::Filter::Crypto Fails Cheers Rolf _{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :) Wikisyntax for the Monastery}	[reply] [d/l]