Closed rodolfojcj closed 3 years ago
Would it help if I switch to pure JSON
as I did in Crypt::JWT
? I do not like the idea of __DIE__
handler.
Does it mean that Cpanel::JSON::XS
would not be needed? If yes, I assume that will work for my use case, given that the system already has these modules installed:
JSON
(version 4.02).JSON::XS
(version 4.03).Thank you.
Hello.
I would like to know if you plan to implement the change previously mentioned at https://github.com/DCIT/perl-CryptX/issues/72#issuecomment-848181572?
If yes, do you estimate a date for a release containing it?
Thanks again.
Yes, I plan to switch to pure JSON.
FYI, this is a regression as JSON.pm is a poor wrapper module which does not use Cpanel::JSON::XS when available - JSON::XS contains a number of bugs so it's best to allow the option of using the fork. If you want to depend on a single wrapper module, I suggest https://metacpan.org/pod/JSON::MaybeXS
Hello.
What do you think about improving the
lib/CryptX.pm
file to add a$SIG{'__DIE__'}
handler, so that itsBEGIN
block looks like this:The reason is that without such
$SIG{'__DIE__'}
handler, the execution of any of the threeeval { require ... }
statements generates__DIE__
signals when eitherCpanel::JSON::XS
orJSON::XS
orJSON::PP
are not installed in the system.A symptom of that situation is that messages like this are fired up to the calling code:
That message comes from a local installation of mine, which does not have
Cpanel::JSON::XS
installed.I think that change is justified by the following explanation given at the Perl documentation for the eval-BLOCK form:
Also, the Perl documentation for the %SIG variable mentions this:
In my particular case, the proposed change will help with these:
Cpanel::JSON::XS
, which is not strictly needed.Can't locate Cpanel/JSON/XS.pm in @INC...
messages, which do not strictly mean an error, are useless and end filling some log files of the system.systemd
from adding an error line to the output of the commandsystemctl status myprogram.service
for a system service of mine, which indirectly depends on theCryptX
library.If I can help with something, please let me know.
Any other alternative implementation, or any other suggestion you may have to handle such
__DIE__
signals, will also be welcome.Thanks in advance.