mirror of
https://git.proxmox.com/git/pve-common
synced 2025-04-28 12:10:17 +00:00
tools: explain reason for the explicit PerlIO load
Explain the reason for the explicit `use PerlIO::scalar;` statement
introduced in c4945bf
("tools: load PerlIO explicitly to avoid odd
failures")
Signed-off-by: Filip Schauer <f.schauer@proxmox.com>
This commit is contained in:
parent
5d5b3abe6d
commit
ad169fbd08
@ -290,12 +290,12 @@ sub file_set_contents {
|
||||
} else {
|
||||
# Encode wide characters with print before passing them to syswrite
|
||||
my $unencoded_data = $data;
|
||||
# Without this we get some "Can't locate PerlIO.pm in @INC" errors _sometimes_, and the
|
||||
# odd thing about it is that they can be "fixed" by calling file_set_contents in the
|
||||
# parent methode/code before the method, from another module, is called.
|
||||
# Anyway, loading PerlIO here should be fine as the in-memory variable writing is in
|
||||
# fact backed by the PerlIO based "scalar" module. This comment can be removed once the
|
||||
# odd behavior is really understood.
|
||||
# Preload PerlIO::scalar at compile time to prevent runtime loading issues when
|
||||
# file_set_contents is called with PVE::LXC::Setup::protected_call. Normally,
|
||||
# PerlIO::scalar is loaded implicitly during the execution of
|
||||
# `open(my $data_fh, '>', \$data)`. However, this fails if it is executed within a
|
||||
# chroot environment where the necessary PerlIO.pm module file is inaccessible.
|
||||
# Preloading the module ensures it is available regardless of the execution context.
|
||||
use PerlIO::scalar;
|
||||
open(my $data_fh, '>', \$data) or die "failed to open in-memory variable - $!\n";
|
||||
print $data_fh $unencoded_data;
|
||||
|
Loading…
Reference in New Issue
Block a user