Eval creates major security issues if improper used.

Wrong. That problem only exists with the string form of eval, not the block form shown, which is the standard Perl equivalent of the try()/catch() pairing found in other languages. Ie. it is the proper way to do this.

2. I don't like die

Your prerogative, but it is a standard language facility and deciding you don't like it is arbitrary. Also, remember that not all Perl programs are "web applications".

Wrong. That problem only exists with the string form of eval, not the block form shown, which is the standard Perl equivalent of the try()/catch() pairing found in other languages. Ie. it is the proper way to do this.

I know you're using it the proper way, but i only state to be careful with it and that you absolutely should know what you're doing, (As stated if improper used.. Thats why i try to avoid the usage of it, a mistake is easily made like this:


#!/usr/bin/perl -w
use stritct;

my $c1 = 'system("touch /tmp/test1.txt")';  
my $c2 = 'system("touch /tmp/test2.txt")';  

#used as string (Dangerous!!!)
eval $c1;

#used as block (ok)
eval {$c2};  # <- gives a useless use of private variable in void cont
+ext.
[download]

.
"We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise." - Larry Wall.

You can think of the two versions of eval as completely different 'functions' (although the block form is not a function - it's a flow control statement(?)). Perhaps they should actually have different names, because they do completely different things.

String eval takes a string, interpolates varibles, and executes the string as Perl code. You use this to delay the evaluation / parsing of whatevers in the string to run-time. It allows you to build Perl programs on the fly and run them. The reason it's dangerous is because the temptation is there to insert user input into the string, effectively allowing the user to execute arbitrary code.

Block eval doesn't have this issue because the code inside it is parsed at the same time as the rest of the code in the program. Therefore, user values can't be inserted into the code.

The primary use of block eval is to catch die / croak, etc. Again, this is another slightly strange naming issue in Perl - in this case, your program won't actually die, it just provides a way of exception handling (i.e. passing error information between levels of the application). In most other languages, the block eval is called 'try', and has a corresponding block called 'catch'. In Perl (5 at least, this changes in 6), the same functionality is achieved by eval{} / if ($@).

I suggest you read the eval POD for full details.

I don't like die

/me too. In fact my programs are perfect and never die. Being such a perfect programmer, not only the OS and environment and filesystem they run on are also perfect and never cause failures, etc. but even the users of my programs are perfect (the most prominent one being myself - so that's already a guaranteee!) and never make errors like supplying inexistent files, etc.

Seriously, web development is not the whole world. die is a perfectly valid and handy language feature - indeed for complex applications, possibly running a GUI, it is sensible to adopt other ways round other than dieing, like warning the user and asking for more input. But for a script that expects a filename on the cmd line to parse, I can't see a more intelligent option than to die, if the file does not exist, for example.