> I have tried the solution with eval and it works as I expect so I really appreciate it

Hmmm, sounds like you might be about to rush off and push it into production. :) I feel you should heed haukex's security advice and think harder about your problem before rushing off to implement a string eval solution.

Some sound advice from famous Perl guru merlyn aka Randal L. Schwartz:

No. Do not resort to eval-string if other means are available. You're firing up the compiler (slower than almost any other solution), and exposing yourself to hard to debug and hard to secure practices.

and Mark Jason Dominus (MJD) from this quiz of the week:

A good rule of thumb is that unless what you're trying to do is most clearly described as "compile and run arbitrary Perl code", it's probably a mistake to use 'eval' to do it.

MJD also strongly advises against using a variable as a variable name aka symbolic references ... as does Tom Christiansen in avoid symbolic references (use a hash or a real reference instead).

Update: Confusingly, while string eval should be avoided, block eval is fine (in fact, should be used more often than it is, based on my experiences of pointing out uncaught exceptions during code reviews ... only to be dismayed by the perpetrator saying "Perl has exceptions? Really? I don't see a try keyword" :) ... which illustrates the importance of choosing good names: Perl's block eval should have been spelled try. Larry made a most unfortunate boo-boo in Perl's early days, choosing the same name (eval) for two different things, violating the different things should look different UI principle. Good to see he's fixed this in Raku.

References Added Later

• Re: eval question (avoid string eval References) (2011)
• Re^2: Loading PERL Module from scalar in RAM? (2023)

See Also

• Exceptions and Error Handling References