The only ways to avoid that is to run PHP as your user, which means either banking on the very slim chance that all your users are running PHPSuExec or similar, or making the self-installing script a PHP shell script instead of a web script and have users run it from command line, which again banks on the chance that users will have SSH access (which is a fair bet, but still not everyone does).

I think what’s nuts is that this is definitely not a function. This is a set of *tokens* that halts the compiler—the “__halt_compiler” token followed by a “(” token and a “)” token. It’s a reasonable bit of functionality, but it’s also yet another case of PHP being sloppy about language definition and terminology.

That’s a fair point (evidence here).

Could see a use for digitally signing scripts too.

Really good idea!

Ok, I really don’t see the point of this? Granted, I’m not coming from a php background, but I can’t see much benefit from the examples you’ve provided?
Is it meant to facilitate an equivalent of embedded resources or just as some strange way to install stuff?

Answering the last question first, this enables both – you can embed resources this way which in turn, enables stuff like building installers.

As to the point – specific to installers, in general the mission is to make life easy for end users of PHP applications and (arguable) to discourage them from doing silly things with your code (fudforum is the case in point there).

When it comes to installing a PHP application, perhaps the trickiest issue for many is setting up PHP’s include paths correctly. For people writing applications, the easiest approach, to prevent giving users headaches, is to use relative paths so people can just “unzip and go”. Unfortunately that typically means dropping a bunch of code below the document root which really shouldn’t be there (for security), in particular config files. The other issue with the “unzip and go” approach is you don’t tend to run into problems (like missing extensions) until your application is actually running. An installer can check the environment for requirements in advance.

Arguably fudforum’s installer takes things a step further in that it handles stuff like setting filesystem permissions and, in effect, actively discourages hacking. Depending on your point of view, that can be a very good thing (you know pretty much what a user has installed).

Anyway – this helps in building “self installing” PHP scripts.

P.S.—No ‘a’ in my last name, ‘kay thanks

Whoops – fixed. Got it right last time – 1 in 2 hit rate.

__halt_compiler does exactly what it says, it HALTS the compiler, which means that it doesn’t have to load the entire contents of the file into memory.

Non script data (e.g. inline HTML) is duped and droped into a ZEND_ECHO op so that it can be displayed when script execution reaches that point. If your script simply issues a die/exit, then you’ve copied that stuff into memory for NO REASON. Now apply this to a multi-megabyte script designed to be run in place (rather than executed once at the command line. Feeling wasteful yet?

Add in the fact that that __halt_compiler will populated a magic constant with the boundary of where your code stops and your data begins and suddenly you’re saving the cost of having to look for that delimiter the hard (read: slow, memory expensive) way.

P.S. – No ‘a’ in my last name, ‘kay thanks.

If you have uncompressed data, the parser will die if it encounters duplicate classes (as it should). As such, you can’t include a tarball for PEAR and use PEAR to install it without __HALT_COMPILER();

Hardly nuts.

base64decode() is also noticeably slower. running install-pear-nozlib.phar is literally just as fast as running the install-pear.php that it is based on, and this is with tons of code. Definitely a good thing.