tags:

views:

305

answers:

5

From inside a PHP program I want to know the location of the binary executing it. Perl has $^X for this purpose. Is there an equivalent in PHP?

This is so it can execute a child PHP process using itself (rather than hard code a path or assume "php" is correct).

UPDATE

  1. I'm using lighttpd + FastCGI, not Apache + mod_php. So yes, there is a PHP binary.
  2. eval/include is not a solution because I'm spawning a server which has to live on beyond the request.

Things I've tried and don't work:

  • $_SERVER['_'] looks like what I want from the command line but its actually from an environment variable set by the shell of the last executed program. When run from a web server this is the web server binary.
  • which php will not work because the PHP binary is not guaranteed to be the same one as is in the web server's PATH.

Thanks in advance.

+1  A: 

Yeah, $_SERVER['_'] is what you're talking about, or as near as exists. The reason you're getting a Web server binary when it's run from the web is that /usr/bin/php has nothing to do with the Web server's execution; what it's running is a separate SAPI. There's nothing from the web PHP instance to point to /usr/bin/php because there's no reason for there to be.

chaos
No reason... except the one stated in my question.
Schwern
@schwern: but if the executable is the web server and php is just used as a library, why would there be a reason to point to a php binary if it isn't used. There is a difference with how web servers use perl because in most cases the interface is CGI and that means running the perl executable (there are exceptions).I'd say your best bet is a configuration string or use eval() if that is good enough for your needs.
Fredrik
@Schwern: If you *deleted* `/usr/bin/php`, your Web server would continue to process PHP files just fine. I don't know how to tell you why there's no *technical* reason for a linkage between them any more clearly than that.
chaos
There is a world beyond Apache. I'm using lighttpd + FastCGI. PHP is not embedded in the web server. In fact, its not even on the same machine!
Schwern
The thing is that using it like that is the exception. It is not "beyond Apache", more or less every server uses php the same way as apache does as it is the most efficient way. Good thing you edited your post to indicate that it wasn't a standard solution but a very installation specific one you were after.
Fredrik
Apparently it's so standard that your lighttpd + FastCGI implementation doesn't even recognize itself as being something else, if it's reporting the Web server process as `$_SERVER['_']`.
chaos
+1  A: 

The PHP_BINDIR constant gives you the directory where the php binary is

Lepidosteus
Closest thing I've heard yet, thanks.
Schwern
Yet some people vote me down, probably because they didn't test it :) Glad to help.
Lepidosteus
A: 

Depending on the way php is installed you CANT find the php executable. if php is running as a module for the webserver like apache module, then there is no binary you can call. you can take a look into php_info() it lists everything. may also the path to php. within that path you can assume a php binary.

but why do you want to call a extra process? you can execute other php files by include command or eval. there is no reason to spawn a new process.

Bernd Ott
Perhaps I want to spawn a server?
Schwern
+1 simply because I don't see a reason for this one to be -1
Fredrik
A: 

what about: <?php exec("which php"); ?>

But, it's unix/linux only:D

silent
There's absolutely no guarantee that the PHP binary which ran the program is the same as the PHP binary in your path. In my situation this is explicitly not so.
Schwern
A: 

The PHP_BINDIR constant is probably the easiest thing to use; the next best thing I could come up with is basically re-creating that bindir path from the extension_dir configuration setting:

$phpbin = preg_replace("@/lib(64)?/.*$@", "/bin/php", ini_get("extension_dir"));

It has a regex in it, so it feels more like your native perl(!) but otherwise is not especially optimal.

Wez Furlong