Well for me, maintainability should be one of our highest concerns as developers: will the developer who follows me understand my code? But that's probably a good subject for a meditation later!

You're close with catching the error; this should work:

Basically, you don't need the if; the left hand side of the expression will be undef (false) if it fails, so the or will evaluate the right hand side. You'll see this form of error catching quite a bit, especially when using open and the like to operate on files. Note the use of $!, which will tell you what the system error message was - see perlvar for more information about this.

Fantastic reply!

Explanation of such things as: Use of if, or and $! greatly appreciated. One of those posts that makes brings together lots of snippets from here and there to create something far greater than the sum of it's parts.

If I can vote for this reply I will, though it'll have to be tomorrow, my 5 for today have been spent.

Your test is mixing two different kinds of conditional, the 'if' and the 'or' types.

If/Unless version:

unless ($var = `system thingy`) {
  die "Failed to get return from call to system\n";
}
[download]

Or version:

$var = `system thingy` or die "Failed to get return" from call to syst
+em";
[download]

Overall good coding style. Nice and readable. If all the code I had to do maintenance on was so readable I'd be a very happy bunny.

Update: Changed the if to an unless since I totally messed up the logic. Oops. Thanks 2mths for pointing that out, shall try and engage brain earlier next time.

Update: Fixed the missing ` problem. Thanks parv. Also updated brain to test all Perlmonks submissions to avoid silly mistakes like this in future.

Again, a very welcome and highly appreciated post, highlighting to me the existance of and difference between "if" and "or".

I won't pretend to understand the meaning of precedence in this context but I don't think that stops me understanding the pertinent points of your post.

That said, looking closely at the if solution I would have thought that would die if the system call actually succeeded. Am I missing something?

No, you're quite right. I was being stupid and messed up, will correct that in a second so as not to confuse others.

The precedence issue is moderately easy to explain in this context. There's a standard Perl idiom

open FILE, "file.txt" or die "Error: $!\n".

This is the equivilent to

open (FILE, "file.txt) or die "Error: $!\n"

as the 'or' is evaluated after the open command.

If you were to try

open FILE, "file.txt" || die "Error: $!\n"

you may be surprised to know you'll never get the error message, this is because the || operator is evaluated before the open and so this is actually equivilent to

open FILE, ("file.txt" || die "Error: $!\n")

and so would only die if the string literal "file.txt" was blank. Not good. You get a similar thing with thing happening quite often.

Moral of this story: Generally use || for defaulting values ($a = $b || $c), but use 'or' for logic control similar to the above.

Oh yeah, and make sure your code dies when it gets an error, not when it doesn't.. I seem to have failed on this one

Molt, the unless version will not work due to missing "`" in the condition.