In Writing a PHP polyglot, I wrote about the Unix ‘shebang’ mechanism. Any script, being shell script, Perl, PHP or any other language, will be started by the shell; and any script can have a very special line in the beginning, that looks e.g. like this:

#! /usr/bin/perl -w

The #! means so much as: ‘use the following command to run this script’. And then the name of the program to use follows. Now the shell knows what to do with this program, and does that instead of trying to interpret the file itself.

Indeed, the rest of the article was about an amusing way to get something like that to work; read it if you want to know weird stuff about batch language.

A more general approach

Although writing a polyglot is fun, it hardly counts as a good solution. There is a much easier solution in Windows, via so-called ‘file type associations’. It can be done from your command line, and goes something like this: first, you tell Windows that a file ending in .pl is a Perl file:

c:\> assoc .pl=Perl

And then you explain what Windows should do with a file of that new type:

c:\> ftype Perl="C:\Perl\bin\perl.exe" "%1" %*

And now you run your Perl script:

c:\> pi.pl
3.14159265358979

There you go. Windows will remember from now on what to do with Perl files, and you don’t need any special code. Exactly the same thing could be done for PHP files, or for any other file type your system supports.

(What strikes me as odd is that assoc is used to tell the system what file type a file with a certain extension is, and ftype then associates this file type to a command. But that’s probably just me.)

This might actually be better than a shebang

There is an interesting advantage to this mechanism above the polyglot way, or even the shebang concept: these are systems settings. That means that on a correctly configured system, it will always work. In the PHP polyglot, the full path name to PHP was specified, because it is not on your path by default. In a shebang, it is actually required that a full path is used. But what if your system doesn’t have PHP in /usr/bin/php, but in /home/dnicolaas/myownphp/php? Then the script doesn’t work and needs editing. Of course it could work if you could specify a command without a full path, but changing all version of Unix is outside the scope of this article.

A clever workaround?

The problem was recognised by Unix experts, and in some scripts you will see this instead:

#! /usr/bin/env perl -w

Here, the full path to perl isn’t specifed. So what is /usr/bin/env? It is not a program that knows how to interpret a language specified in its second parameter;  it just runs all its arguments as a command in a copy of the environment. In other words, it runs

perl -w

in a new shell. And since this new environment will just look up perl in the path, this gets around the requirement that perl gets specified with a full path. It exchanges it for the requirement that /usr/bin/env exists, of course, but that usually does. Except that on some systems it doesn’t, so this workaround is not perfect.

… or maybe not?

There are two things that are not so nice about the file type associations: they require your to give your scripts a unique extension, and they even require you to type that extension when you want to run the program. When I want to know the value of π, I don’t need to know which programming language I used; I’d rather type

pi

than

pi.pl

Another disadvantage is that if I get a script from a Unix user (or even a whole collection of scripts,) I have to rename them before I can use them. The first problem can be solved in Windows by setting the PATHEXT variable:

set PATHEXT=%PATHEXT%;.pl

This turns .pl into a so-called executable extension; Windows now knows that files with the .pl extension can be typed on the command line without the extension, much like files ending in .com, .exe and .bat.

The second problem cannot be solved so easily. Renaming files acquired from somewhere else is never nice: it is work, it requires thinking when upgrading to a new version, and it might break installers. Is there anything we can do about that?

Running extensionless scripts

So let’s assume a Unix programmer gave us a little Perl script that reads like this:

#! /usr/bin/perl
use Math::Trig;

print "The trip around a planet with radius $ARGV[0] is ";
print pi * 2 * $ARGV[0];
print "\n";

It’s called circ, and you can invoke it as follows:

$ circ 6371
The trip around a planet with radius 6371 is 40030.1735920411

At least, that is what your Unix friend said. But all you get is this:

c:\> circ 6371
'circ' is not recognized as an internal or external command,
operable program or batch file.

But couldn’t we use ftype and assoc to associate the empty extension?

c:\> assoc .=Perl
.=Perl

c:\> ftype Perl="C:\Perl\bin\perl.exe" "%1" %*
Perl="C:\Perl\bin\perl.exe" "%1" %*

c:\> circ 6371
'circ' is not recognized as an internal or external command,
operable program or batch file.

Why didn’t this work? Because we didn’t specify the empty extension as an executable extension. Windows faithfully adds all executable extensions to ‘circ’ to make it run, but it doesn’t add the empty extension if you don’t tell it to:

c:\> set PATHEXT=%PATHEXT%;.
c:\> circ 6371
The trip around a planet with radius 6371 is 40030.1735920411

So there we are! Now we can run any Perl script that we get from our Unix friends!

Another extensionless script

So let’s assume a Unix programmer gave us a little PHP script that reads like this:

#! /usr/bin/php
<?php
print "The volume of a planet with radius $argv[1] is ";
print pi() * 4 * pow($argv[1],3) / 3;
print "\n";
?>

And it’s called volu, and meant to be run like this:

$ volu 6371
The volume of a planet with radius 6371 is 1.08320691685E+012

Ouch. That won’t work, will it? Since we associated the empty extension with Perl, Windows will insist on running Perl on this script. And it isn’t Perl.

Perl tries, I must admit. But Perl doesn’t know we’re running on Windows, so Perl tries to run the program specified in the shebang line:

c:\> volu 6371
Can't exec /usr/bin/php at volu line 1.

But hey! That may be the solution. What if we associated the empty extension with a program that reads shebang lines, and runs the Windows equivalent of the command specified in the shebang line?

A Windows shebang

So let’s try this:

c:\> assoc .=shebangfile
.=shebangfile

c:\> ftype shebangfile=shebang.bat "%1" %*
shebangfile=shebang.bat "%1" %*

c:\> set PATHEXT=%PATHEXT%;.

Now we have arranged that every extensionless file will be run with shebang.bat, so this:

c:\> volu 6371

will turn into this:

shebang.bat c:\volu 6371

Now the only thing we need to do is create shebang.bat, and put it in your path (your c:\WINDOWS directory is fine.) What shebang.bat does is exactly the same as what the shell on Unix does: it reads the first line of the file, extracts the command from it, and runs it with the whole command line as arguments. Since we don’t want to know where on Windows Perl or PHP are installed, and we don’t mind being a little better than the original shebang solution, shebang.bat just extract the last bit (the command name) from the path and runs that, effectively assuming it’s on your path. So the above command translates to:

php c:\volu 6371

which works like a charm.

Here’s shebang.bat:

@echo off
rem shebang.bat - Unix shell behaviour from windows.
rem Use
rem     assoc .=shebangfile
rem     ftype shebangfile=shebang.bat "%1" %*
rem     set pathext=%pathext%;.
rem and put this somewhere in your path.
rem Author: Dion Nicolaas <dion@nicolaas.net>
rem http://whitescreen.nicolaas.net/programming/windows-shebangs
rem 
rem Get the first line of the file
set /p line=<%1
rem Remove all quotes from the string, they shouldn't be there anyway
set line=%line:"=%
rem turn each part of the path into a quoted string, separated by spaces
set line="%line:/=" "%"
rem set first to the first part ("#!"), last to the last part (e.g. perl -w)
for %%i in (%line%) do call :firstlast %%i
rem if it was a shebang line, set command accordingly, else use "type"
set command=type
if "%first%"=="#!" set command=%last%
if "%first%"=="#! " set command=%last%
rem Run command on the command line
%command% %*
goto :EOF
:firstlast
rem Get first and last token, unquote in the process (which will also strip 
rem spaces). In Unix scripts 'perl -w' is much more likely than "the language
rem processor" (long file name with spaces)
if "%first%"=="" set first=%~1
set last=%~1

There’s nothing very special about this batch file. It’s just that batch language is not very good at text processing.

There is one special case that wasn’t mentioned before: What if a file doesn’t have a shebang line? On Unix, a script without a shebang line is assumed to be a shell script, but only if it’s permissions show it is an executable file. On Windows that would be a bit dangerous, because we just designated every extensionless file executable: that includes README and TODO and other files that are probably just text. So if a file doesn’t start with ‘#!’, we just run it through ‘type’, which effectively displays it on the screen.

Epilogue

One more thing: changing PATHEXT from your command line is temporarily. If you want this to work permanently, you need to edit your environment differently: Click ‘Start’ / ‘Control Panel’ / Double-click ‘System’ / ‘Advanced’ tab / button ‘Environment Variables’. Then find ‘PATHEXT’ in the ‘System Variables’, ‘Edit’ it, click a few OKs and open a new CMD window. Your old, already open windows will NOT magically get the new version of PATHEXT, but all your new ones will.

This version of shebang.bat only support shebang lines like this:

#!/usr/local/bin/php
#! /usr/local/bin/perl -w

When run with a file that starts with

#! /usr/bin/env perl

it will fail:

'env' is not recognized as an internal or external command,
operable program or batch file.

But env.bat is very easy to implement on Windows. Just store it somewhere on your path as well:

@%*

This looks like cursing, but it actually means: run %* (all parameters to this batch), but don’t echo it (the @ suppresses output.) This might not catch all subtleties of the Unix ‘env’, but for our purpose it will do just fine.

Sometimes, it is very useful to run a PHP program from the command line. When you want to try out a small feature; when batch language just doesn’t do it; or when some of PHP’s powerful library functions (like fopen()) come in handy. However, running a small program like that is always a bit clumsy. First of all, PHP is usually not in your path; and wouldn’t be nice if you could just type the name of the program and run it?
Take this simple PHP script:

<?php
print date('r', $argv[1]) . "\n";
?>

If you ever store dates as a time(), i.e. the number of seconds since 1 January, 1970, you know how useful this is. You can call it like this:

c:\php\php.exe -q time2str.php 1234567890

and it will answer with

Sat, 14 Feb 2009 00:31:30 +0100

Indeed, Valentine’s day in 2009.
But the call you have to make is pretty cumbersome. So you write a batch file, time2str.bat, that looks like this:

@c:\php\php.exe -q time2str.php %1

and now you can just type

time2str 1234567890

to get your result. You stuff both files somewhere in your path, and when you remember about it a few days later, you type:

time2str 1234567890
Could not open input file: time2str.php

Hmm. Of course you are running from another directory now. So now you should hardcode time2str.php’s directory. Or time2str.bat should be smart enough to find out its own directory, and then find the PHP file in it. This batch file starts to become a nuisance.

The Unix shell can do it

In Unix and Linux, there is a good solution for this. Any script, being shell script, Perl, PHP or any other language, will be started by the shell; and any script can have a very special line in the beginning, that looks e.g. like this:

#! /usr/bin/perl -w

The #! means so much as: ‘use the following command to run this script’. And then the name of the program to use follows. Now the shell knows what to do with this program, and does that instead of trying to interpret the file itself.
Now that would be nice on Windows! Unfortunately, it doesn’t exists. What does exist is the ‘executable extension’: if you double-click on a file called something.doc, the application handling DOC files is started. What not everyone knows, is that this also means that if you type something.doc at the command line, that application is started. But to enable this, you have to change global settings on your system, and in case of PHP, there is a clear drawback: if you now double-click a PHP file, it will be executed in a DOS window that disappears immediately after the program ends. It makes more sense to associate PHP files with your favourite editor!

… but a polyglot can, too

The solution presented here was inspired by Perl, for which a similar trick trick exists to make Perl scripts execute on Windows. The idea is to turn the PHP file into a batch file that runs PHP on itself. But that is easier said than done…
Here’s an outline of the task. We want a PHP program to run from the command line. To achieve this, we turn it into a batch file. That batch file contains both instructions in batch file language to run PHP, and the actual PHP program that is being executed. The two problems are that PHP should completely ignore the batch instructions, whereas the batch interpreter, CMD, should ignore the PHP code. A program that runs in two languages is usually called a polyglot; strictly speaking, a polyglot should do the same in both languages, but this is a more practical example.

Let’s just start somewhere

Here’s the first take. Let’s create a batch file called str2time.bat that contains the following:

@c:\php\php.exe -q %~f0 %*
@goto :EOF
<?php
 print date('r', $argv[1]) . "\n";
?>

The first line runs PHP (or more precisely, c:\php\php.exe) on the file indicated by %~f0. This is batch-speak to point to the full path of %0, and %0 is the command itself. So %~f0 expands to the full path of the batch file time2str.bat itself. %* stands for all command line parameters except %0. They will be passed to PHP, which will handle them.
The second line skips to the end of the file. the label :EOF is always implicitly present in batch files. This makes sure the rest of the file, in this case the PHP code, is completely skipped bij CMD. A feature of CMD that is in this case helpful is that it will not read the skipped lines at all. The batch file will run without error messages, even though these lines are not valid batch syntax.
The @-characters in the first two lines make sure that those lines are not echoed by CMD before they are executed. The same can be achieved by starting the batch file with @echo off, but this is shorter.
Then follows the PHP code, but the batch interpreter blindly ignores all that; it just jumps to the end of the file and exits. So half of the task is done!
If you run this, you will see the following:

@c:\php\php.exe -q %~f0 %*
@goto :EOF
Sat, 14 Feb 2009 00:31:30 +0100

Here the burden of the polyglot programmer shows: who produced this output? PHP or CMD? In this case, it is pretty easy to sort out: it was PHP. In PHP, everything that appears outside <?php and ?> will be printed literally. So the first to lines of our PHP script are the first line of our output. The the rest is executed, and the correct answer is printed: Valentine’s day.

‘Shut up, PHP!’

So now the task at hand is this: make sure the file starts with <?php. How about:

<?php /*
@c:\php\php.exe -q %~f0 %*
@goto :EOF
*/ ?>
<?php
 print date('r', $argv[1]) . "\n";
?>

What is done here is twofold: first of all, we start the file with a PHP opening tag, to make sure the batch lines are not printed; and secondly, we place comment brackets around the batch lines, to make sure PHP doesn’t try to execute them! So we now have hidden the two lines of batch instructions from PHP. Let’s try; do you feel what’s coming?

/*0<?php
The filename, directory name, or volume label syntax is incorrect.
Sat, 14 Feb 2009 00:31:30 +0100

Whoops. What is this? And again: Who produced this output?

‘… and you too, CMD!’

This time, it’s the batch interpreter that is complaining. First of all, it echoes the first command it encounters in the file:

/*0<?php

What it really wanted to say was this:

/* 0< ?php

which is the long version of:

/* < ?php

What you see here is a redirected input command, much like e.g.

sort < records.txt

In CMD, you are allowed to reverse the order of the parts, and write

< records.txt sort

To be helpful, when echoing the command, CMD will put it in the right order. In our polyglot, we see that CMD actually tries to execute the command /* and uses ?php as input.
After executing this command, CMD produces an error message:

The filename, directory name, or volume label syntax is incorrect.

That’s the second line of the output. The reason for this error message is that the filename ?php is not valid for redirecting: it contains a wildcard (?), and CMD cannot handle that.
The last line is our output from PHP, which is just how we want it. So now the PHP problems are solved, but we have two new, batch-related problems: the first line is now echoed by CMD, and produces an error when executing because the syntax is incorrect. How do we hide this line from CMD?
Polyglot programming is a bit like running in circles; every time you solve a problem in one languages, you create a new problem in the other language. Luckily, the problems are becoming smaller in the process.

Do nothing in two languages

The fact that CMD reversed the order of the parts is the key. In batch files, you can make sure lines are not executed at all by starting them with a :-character. This is different from a rem-statement; the latter is executed, and echoed if echo is still on. In fact, : is a very powerful character, as you can see in the next version:

<?php/* :
@c:\php\php.exe -q %~f0 %*
@goto :EOF
*/ ?>
<?php
 print date('r', $argv[1]) . "\n";
?>

In this version, two things are changed in the first line: first of all, the PHP comment opening is placed directly after the PHP opening tag; and secondly, the :-character is added. Now here is a surprise; CMD will be smart enough to reverse the order of the parts, but after that, it will find out it has nothing to do! CMD will execute the following line:

: < ?php/*

But since lines starting with a : are completely skipped, CMD doesn’t even look at the filename anymore. By concatenating the PHP opening tag and the comment opening, we created a longer, even more illegal filename ?php/*, which is ignored completely. But in the file, the :-character appears inside the PHP comment, so PHP doesn’t care about it at all.
And this is it! If we run this batch file, we get:

Sat, 14 Feb 2009 00:31:30 +0100

And that is exactly the output of PHP we want.
Voila! Four lines of polyglot that you can just prepend to every PHP program to make it run from the command line. Three lines more than Unix, but it makes for a much more interesting read.

Appendix

Below is the file with simple syntax highlighting, first the batch version, then the PHP version. Special words and characters are purple, comments are green, and functions and variables are blue. The grey part in the batch file is mostly invalid syntax, but is never reached.
One more thing: since everything after the : in the first line is seen as a comment in both PHP and batch language, you can really write a comment there. I inserted some sort of small signature there.

Batch

<?php/* : http://whitescreen.nicolaas.net/php_polyglot.php
@c:\php\php.exe -q %~f0 %*
@goto :EOF
*/ ?>
<?php
    print date('r', $argv[1]) . "\n";
?>

PHP

<?php/* : http://whitescreen.nicolaas.net/php_polyglot.php
@c:\php\php.exe -q %~f0 %*
@goto :EOF
*/ ?>
<?php
    print date('r', $argv[1]) . "\n";
?>

The White Screen already exists for a while, but it was never easy to add to that… Which probably means that some knowledge remains unknown. Let’s try this way…