Spam from

Today I got this spam message:

From: Tessel van Leeuwen <>
Subject: Invitation: Join the Apps for Europe competition and win 5,000 euro!
To: undisclosed-recipients:;


I'm writing to you because I found your email address on the website,, and I would like to invite you to enter the Apps for Europe competition: ... <snip>

There are a couple of things about this I find interesting:

  1. As far as I can tell, my email address is not on the linked page.
  2. The message has no visible recipients (so I guess my address was listed in BCC).
  3. I've never done anything with apps.
  4. The Austrian Perl Workshop was 2 months ago. Why harvest the hackathon page for email addresses now?

PHP puzzle

So I've decided to make a little PHP puzzle.

The following program contains 3 test cases that you need to make pass. To do that, you should replace XXX in the assignments to $a, $b and $c by the right magic values.

header('Content-Type: text/plain');

function t_1($x) {
    switch ($x) {
        case 'one': return false;
        case 0:     return !is_string($x);
        default:    return false;

function t_2($x) {
    $k = array('one thousand', 2000, 'a363b8d13575101a0226e8d0d054f2e', 'php');
    return in_array(md5($x), $k);

function t_3($x) {
    $k = '1020304050607';
    $x = (string)$x;
    return strlen($x) < strlen($k) && $x == $k;

echo "1..3\n";

$a = XXX;
echo t_1($a) ? 'ok 1' : 'not ok 1', "\n";

$b = XXX;
echo t_2($b) ? 'ok 2' : 'not ok 2', "\n";

$c = XXX;
echo t_3($c) ? 'ok 3' : 'not ok 3', "\n";

If you've done everything right, the output should look like this:

ok 1
ok 2
ok 3

(Thanks to for inspiration.)

Cool things you can do with Perl 5.14

Perl 5.12.0 introduced pluggable keywords. This feature lets a module author extend Perl by defining custom keywords, at least as long as that module author knows XS and how to construct OP trees manually.

Perl 5.14.0 added many functions to the API that make custom keywords worthwhile (especially the ability to invoke the Perl parser recursively in order to parse a custom syntax with embedded Perl fragments).

So what can this be used for? In the following, I'm going to show you three modules I've written that make heavy use of custom keywords.

C Programming: What is the difference between an array and a pointer?

Why is a raven like a writing-desk? (Lewis Carroll)

This is a copy of an article I wrote a long time ago. I'm putting it here to give it a more permanent home. Sorry for being off topic again!


I'm glad you asked. The answer is surprisingly simple: almost everything. In other words, they have almost nothing in common. To understand why, we'll take a look at what they are and what operations they support.

Exit statuses and how $? works

The other day I was wondering about $? in Perl and the shell and how exit statuses work. I did some digging and now I'd like to talk a bit about exit statuses at the OS level and how Perl and the shell deal with it.

First off, there are two ways a unix process can terminate. One is by calling _exit, the other is getting killed by a signal. In both cases the resources of the process (such as memory or file descriptors) are cleaned up. All that remains is an entry in the process table (i.e. the PID is still taken) and some status information on how the process died. This "stale" process table entry is called a zombie process.

After a process has terminated, it's its parent's job to clean up after it by calling wait or simply exiting itself (a process whose parent has died is known as an orphan process; it will be adopted and cleaned up by init, the process with id 1).

In C, a successful call to wait gives you a status value of type int. The header <sys/wait.h> provides several macros to examine this status, such as:

  • WIFEXITED - true if the process died by calling _exit
  • WEXITSTATUS - the number passed to _exit (only valid if WIFEXITED is true)
  • WIFSIGNALED - true if the process was killed by a signal
  • WTERMSIG - the signal that killed it (only valid if WIFSIGNALED is true)

Something that may not be obvious: the "exit status" consists of a single byte, so only the 8 lowest bits of the number you pass to _exit will be used. In other words, WEXITSTATUS will always be in the range [0, 255].

The above interface is fairly abstract; it doesn't define the details of how signal numbers and exit statuses are encoded. But there is a traditional way unix has done this, and it's also how Perl does it.

  • The status value in $? is a 16-bit number.
  • The low 8 bits are set if the process died from a signal.
  • The low 7 bits are the signal number; bit 8 is set if the process dumped core.
  • Otherwise the exit status is stored in the high 8 bits.

Perl always computes $? to look like this, even if your OS doesn't encode status information this way natively. This means a C program may get different status bits from wait than what a Perl program would see in $?. If you really need your OS's native status code in a Perl program, you can use ${^CHILD_ERROR_NATIVE} and the W* functions from POSIX.

(The following information was taken from the bash manual but it probably applies to all Bourne-style shells.)

Finally there is another $? variable in the shell. It has the same name and function as Perl's, but its values work differently. In particular, it's always an 8-bit number, not 16 bits as in Perl.

  • If a process exits normally, its status is in $?.
  • If it is killed by a signal, $? is set to 128 + $signo (where $signo is the signal's number).

Example: On my system SIGSEGV is 11, so after a segfault the shell sets $? to 128 + 11 = 139.

Other synthetic $? values include 127 (command not found) and 126 (command found but it wasn't executable).