As a shell script, anything starting with `#`, `true<WS>` and `false<WS>` are meant to be ignored and variable declarations are compatible with Make. The next lines to be executed are therefore `make -f $0 $1` and `exit 0`, as you would expect. Shell scripts are parsed linewise so subsequent lines are ignored.

As a Makefile, again `#` lines are ignored and variable declarations are compatible but lines starting with `true<WS>` and `false<WS>` have to be a valid construct, so they are made into rules. Make doesn't rely much on the rule's recipe (you can do way more weird things by setting `SHELL` to non-shells by the way!), so indented lines are essentially ignored unless the rule is triggered. Next lines are usual stuffs for Makefile. As `true` (and anything follows, see the next paragraph) would be the first and thus default rule target, it has to trigger `all` manually and ensure that `all` is always executed in this way by setting the final `.PHONY` rule.

As a C source code, `#` lines are now preprocessor directives and used to hide the first `true` token from the compiler. As an identifier followed by a colon wouldn't be a valid C code at the top level, `true` should be followed by a comment which extends to the second-to-last line. (There is no technical reason for `*/` to be a requisite here I believe.) The final line is an usual indented C code, which is a part of `.PHONY` which recipe is ignored. Since Make will interpret `/*` as path patterns, they have to be also handled by `.PHONY`.

Nice. I worked out most of it; the C source part was easy and the Makefile was mostly comprehensible(except for the "true"/"false" rules) but the shell script part was what stumped me; now i see the sneaky whitespace in "false :".

A true IOCCC winner.

One tip for folks trying to figure out this (and other multi-modal) code is to use your editor's syntax highlight feature based on filetype. So for example in vim renaming this file to ".sh" and ".mk" gives you shell script and makefile structures.