in reply to Accessing variables in an external hash without eval

Consider using a different storage format. I would choose JSON:

FormatHuman readableArbitary structures
(See update below)
8-bit cleanVersion independantCross languageMay execute code from fileUnexpected network accessMemory usage attackComments
Perl source code (generated manually or by tools like Data::Dumper)kind ofyesyesmostlyno (only perl can parse Perl)yesby executable codeby executable codeyes
Storablenoyesyesno (depends on Perl version, limited compatibility with other versions)nonononono
  • \x00 is illegal in XML, workaround like base64 required
  • any amount of whitespace is often treated as a single space (CDATA required)
YAMLyes (but with strange rules)yesyesyesyesyes (may be disabled)by executabe codeby executabe codeyes
JSONyesyesyesyesyesnononono (but some parsers allow Javascript or shell comments)
INIyesno, only HoHno (escaping rules depend on reader and writer)yesyesnononoyes
CSVyesno, only 2D-Array (AoA)no (escaping rules depend on reader and writer)yesyesnononono

See also Re^4: The safety of string eval and block eval. and Re^2: Storing state of execution


"Arbitary structures" was not meant as arbitary as I wrote, thanks tobyink++. It should read something like "any mix of scalars, arrays, and hashes, without circular references, handles, code references, globs".

"Memory usage attack" means that either the parsed file uses significantly more memory (several orders of magnitute) than the file size, or parsing the file may execute code that allocates much memory.

"Unexpected network access" means either that parsing the file completely and correctly may require reading additional data from the internet, or parsing the file may execute code that accesses the network.

"8 bit clean" means that any binary data may be stored and fetched.

Added comments column

Added Data::Dumper


Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)