The Swiss Army Chainsaw... Watch out for your legs there, buddy!

[crashtest]

A short while back I was called in to look at some Perl code that didn't seem to be working right. The script in question had originally been supplied by a vendor, then gotten hacked to pieces by various people in my group, who are by and large Java programmers.

Which might explain the following chunk of code I discovered:

my $param = $cgi->param('foo');

if ($param != null){
   # ... do stuff
}

Since I now spend most of my time in Java as well, it took me a couple of seconds to realize the common idiom variable != null is completely inappropriate in Perl. Without strictures, perl was parsing the condition as $param "not equal to" the string 'null'. Certainly not the intended semantics.

Still, it seemed to me that Perl was conveniently Doing What I/We Meant. If foo was passed in (and its value would almost certainly never be 'null'), then $param didn't equal 'null', and the conditional block would execute. Our problem was that the conditional block was not executing. What was going on here?

Later on the drive home, the light bulb came on. The condition was doing a numerical comparison (!=), not a string comparison! So:

$param != null   # becomes...
$param != "null" # becomes ...
$param != 0

Given that $param only contained straight text (no digits), its numerical value would always be 0. Hence the conditional would never execute.

Anyway, I got a kick out of this. Perl's DWIMmery can be a powerful tool, but also a dangerous hazard in the wrong hands. Swiss Army Chainsaw indeed -- just make sure you stand clear!

[revdiablo]

This is why we yell, scream, and wave our arms about strict and warnings. With warnings, we get:

$ perl -wle 'my $param = "foo"; if ($param != null) {}'
Unquoted string "null" may clash with future reserved word at -e line 
+1.
Argument "null" isn't numeric in numeric ne (!=) at -e line 1.
Argument "foo" isn't numeric in numeric ne (!=) at -e line 1.

And with strict we get:

$ perl -Mstrict -wle 'my $param = "foo"; if ($param != null) {}'
Bareword "null" not allowed while "strict subs" in use at -e line 1.
Execution of -e aborted due to compilation errors.

So, tell your coworkers to use strict and warnings unless they know what they're doing. Which, unfortunately, the code you've shown kind of leads me to believe they don't (at least when it comes to Perl).

[nimdokk]

Been there, done that. Had a Perl script supplied by our vendor, first thing I did with it was run a syntax check - it errored, found the error then told the vendor how to fix it. Also suggested that the script use warnings and strictness. The latest version does (iirc) :-). I'm now debating if I have time to hack the script so that we can use real regular expressions instead of being limited to * and ?. <sigh>

[jZed]

In linguistics, this kind of thing is called a "false friend" -- a word or phrase that means something in a language you know so you use it the same way in another language thinking it means the same thing and get yourself into trouble. The classic is the British soldiers asking if they could "knock up" some American women.

[Anonymous Monk]

line up, wake up, wear out, make pregnant?

[sfink]

Solution (untested):

Step 1:

package Friendly::Hint;
use base 'Exporter';
use Carp qw(croak);

our @EXPORT = qw(null);

sub null {
  croak("ERROR: Java programmer detected.");
}

1;

Step 2:

echo "PERL5OPT=-MFriendly::Hint" > /etc/profile.d/perl.sh