|The stupid question is the question not asked|
Re^4: The safety of string eval and block eval.by afoken (Chancellor)
|on Aug 15, 2016 at 19:51 UTC||Need Help??|
As a very generic rule of thumb: If you think that you need a string eval, you are doing it wrong.
There are very few good reasons for using a string eval, and even fewer if the string eval has to work on input controlled by the user. use, require, and the rare do FILENAME, are of course string evals behind the scenes, and they are useful and the proper way to load perl code from files.
In very rare cases, perl functions have to be generated from data at run time, and at that point, a string eval is actually the best way to solve the problem. But for tasks like parsing configuration files, "variable variable names", constructing variables at run-time, reading data back from stored files (e.g. from Data::Dumper), string eval is the wrong way. Configuration files are better stored as INI files, JSON or XML (all readable and all without executable code). "Variable variable names" and variables constructed at runtime are better implemented via arrays, hashes, or (worst case) symbol table manipulation. And data is better stored using JSON, XML, one of the various "universal" binary storage formats (see Re^4: Storing state of execution -- Sereal?), or the problematic (see Re: Perl Storable problem (i Think) but fast Storable.
And of course, for a quick hack that runs on known data, string eval is ok if it does the job AND the quick hack does not leave your environment. Don't let users use any tool that uses string eval just because it needs less code than a proper solution.
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)