Re^2: Can't get \n or other character/translation escapes to interpolate if originally read from a data file

String::Interpolate

However, it'll also interpolate @{[ `rm -rf /` ]}... depending on how many characters OP wants interpolated, s/\\n/\n/g might be the safer approach.

Comment on Re^2: Can't get \n or other character/translation escapes to interpolate if originally read from a data file Select or Download Code

Replies are listed 'Best First'.
Re^3: Can't get \n or other character/translation escapes to interpolate if originally read from a data file by pryrt (Abbot) on Mar 15, 2021 at 19:06 UTC
Like I said, I had never used the String::Interpolate module before. Because they had the `safe` versions of their functions, I thought that they protected against things like that... but it appears not. If the OP wants more than just \n available as escapes in his processing, however, the list of substitutions will creep up as the rules/desires change... especially with the translation escapes. I was hoping that String::Interpolate was a way to avoid re-inventing that wheel, but I guess not.	[reply] [d/l]
Re^4: Can't get \n or other character/translation escapes to interpolate if originally read from a data file by haukex (Archbishop) on Mar 15, 2021 at 19:12 UTC
Because they had the safe versions of their functions, I thought that they protected against things like that... but it appears not. Safe can in theory protect against some attack vectors. But IMHO the major issue with that module is that its protection depends on blocking/allowing specific opcodes, which can change depending on Perl version, and AFAIK even which opcodes do what can change across Perl versions. So it requires deep knowledge of the internals, and even then it can't promise complete safety. Even though being able to eval Perl code "really safely" would be a nice thing to have, I would always strongly recommend against relying on Safe...	[reply]