By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,955 Members | 1,768 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,955 IT Pros & Developers. It's quick & easy.

Which PHP am I running?

P: n/a
Is there a way to determine the path to the php executable (as opposed
to the script. In other words, I am looking for the path to php.exe or
php-win.exe) that is currently running (ie. how was this script called)
on Windows (I'm on Win XP Pro)? WScript/CScript (when programming in
VBScript) allow this, for example.

Failing that, is there any way to conclusively determine whether the
script that is running was invoked from php.exe or php-win.exe? I say
conclusively, because often there is a slight difference in the
environment variables, but it need not be the case.

Thanks,
Csaba Gabor from New York

Jul 8 '06 #1
Share this Question
Share on Google+
17 Replies


P: n/a
Csaba Gabor wrote:
Is there a way to determine the path to the php executable (as opposed
to the script. In other words, I am looking for the path to php.exe or
php-win.exe) that is currently running (ie. how was this script called)
on Windows (I'm on Win XP Pro)? WScript/CScript (when programming in
VBScript) allow this, for example.

Failing that, is there any way to conclusively determine whether the
script that is running was invoked from php.exe or php-win.exe? I say
conclusively, because often there is a slight difference in the
environment variables, but it need not be the case.

Thanks,
Csaba Gabor from New York
Running phpinfo() should tell you if its running as a module or cgi. I
believe it also has path information. It is probably in at least one
of the directories of the path variables. Barring all that, you could
search the file system with a script or exec() call

Jul 8 '06 #2

P: n/a
Richard Levasseur wrote:
Csaba Gabor wrote:
Is there a way to determine the path to the php executable (as opposed
to the script. In other words, I am looking for the path to php.exe or
php-win.exe) that is currently running (ie. how was this script called)
on Windows (I'm on Win XP Pro)? WScript/CScript (when programming in
VBScript) allow this, for example.

Failing that, is there any way to conclusively determine whether the
script that is running was invoked from php.exe or php-win.exe? I say
conclusively, because often there is a slight difference in the
environment variables, but it need not be the case.
Thanks for your response:
Running phpinfo() should tell you if its running as a module or cgi.
Yes. And easier is php_sapi_name() [or PHP_SAPI], which produces
apache2handler when I'm running php as a web server module. But it
shows me the same thing when php is started from the command line with
either php.exe vs. php-win.exe: cli. If I try try the same thing with
php-cgi, then I get: cgi-fcgi

So that's why the remaining problem is differentiating between php.exe
vs. php-win.exe
I believe it also has path information.
phpinfo() shows the PATH environment variable. It does not show the
path to the executable, nor does it show the executable name.
It is probably in at least one
of the directories of the path variables.
I agree that it probably is. But even under that assumption, how do
you programatically differentiate between php.exe vs. php-win.exe?
Barring all that, you could search the file system with a script or exec() call
Could you elaborate, please - How does this let me determine the called
executable?

Csaba

Jul 8 '06 #3

P: n/a
Csaba Gabor wrote:
Is there a way to determine the path to the php executable (as opposed
to the script. In other words, I am looking for the path to php.exe or
php-win.exe) that is currently running (ie. how was this script called)
on Windows (I'm on Win XP Pro)? WScript/CScript (when programming in
VBScript) allow this, for example.
As far as I know there is no way, unless you load in a COM object.
Failing that, is there any way to conclusively determine whether the
script that is running was invoked from php.exe or php-win.exe? I say
conclusively, because often there is a slight difference in the
environment variables, but it need not be the case.
No, the only difference between php.exe and php-win.exe is whether a
console window opens or not and you can't detect that programmatically.

Jul 8 '06 #4

P: n/a

Chung Leong wrote:
Csaba Gabor wrote:
Is there a way to determine the path to the php executable (as opposed
to the script. In other words, I am looking for the path to php.exe or
php-win.exe) that is currently running (ie. how was this script called)
on Windows (I'm on Win XP Pro)? WScript/CScript (when programming in
VBScript) allow this, for example.

As far as I know there is no way, unless you load in a COM object.
Loading in a COM object is fine by me, but would you clarify your
remark, please, as to which one to load and how to use it. Or are you
talking about a 3rd party COM object that one must purchase?
Failing that, is there any way to conclusively determine whether the
script that is running was invoked from php.exe or php-win.exe? I say
conclusively, because often there is a slight difference in the
environment variables, but it need not be the case.

No, the only difference between php.exe and php-win.exe is whether a
console window opens or not and you can't detect that programmatically.
Hmm, I'm just wondering about the relationship between the console
window (if it opens) and php. At any rate, thanks for your comments.

Jul 8 '06 #5

P: n/a
Csaba Gabor wrote:
Loading in a COM object is fine by me, but would you clarify your
remark, please, as to which one to load and how to use it. Or are you
talking about a 3rd party COM object that one must purchase?
I had the Wscript.Shell object in mind. I think you can initialize it
in PHP.

Jul 8 '06 #6

P: n/a

Csaba Gabor wrote:
Richard Levasseur wrote:
Csaba Gabor wrote:
Is there a way to determine the path to the php executable (as opposed
to the script. In other words, I am looking for the path to php.exe or
php-win.exe) that is currently running (ie. how was this script called)
on Windows (I'm on Win XP Pro)? WScript/CScript (when programming in
VBScript) allow this, for example.
>
Failing that, is there any way to conclusively determine whether the
script that is running was invoked from php.exe or php-win.exe? I say
conclusively, because often there is a slight difference in the
environment variables, but it need not be the case.

Thanks for your response:
Running phpinfo() should tell you if its running as a module or cgi.

Yes. And easier is php_sapi_name() [or PHP_SAPI], which produces
apache2handler when I'm running php as a web server module. But it
shows me the same thing when php is started from the command line with
either php.exe vs. php-win.exe: cli. If I try try the same thing with
php-cgi, then I get: cgi-fcgi

So that's why the remaining problem is differentiating between php.exe
vs. php-win.exe
I believe it also has path information.

phpinfo() shows the PATH environment variable. It does not show the
path to the executable, nor does it show the executable name.
It is probably in at least one
of the directories of the path variables.

I agree that it probably is. But even under that assumption, how do
you programatically differentiate between php.exe vs. php-win.exe?
Barring all that, you could search the file system with a script or exec() call

Could you elaborate, please - How does this let me determine the called
executable?

Csaba
Sorry, I overlooked the part about php.exe and php-win.exe.

But why does it matter if its using the nix or the windows php
executable? IIRC, php can be invoked using php.exe on both windows and
*nix. Unless there is some very specific reason I don't know about?

If you're worried about differences between environment variables
because of the host OS, then check the OS environment variables and act
accordingly. If you see a X:\ in any of the paths, you can also know
if its windows or nix. same for the include_path directive (unix uses
:, windows uses ;).

Jul 9 '06 #7

P: n/a
Richard Levasseur wrote:
Csaba Gabor wrote:
Richard Levasseur wrote:
Csaba Gabor wrote:
Is there a way to determine the path to the php executable (as opposed
to the script. In other words, I am looking for the path to php.exe or
php-win.exe) that is currently running (ie. how was this script called)
on Windows (I'm on Win XP Pro)? WScript/CScript (when programming in
VBScript) allow this, for example.

Failing that, is there any way to conclusively determine whether the
script that is running was invoked from php.exe or php-win.exe? I say
conclusively, because often there is a slight difference in the
environment variables, but it need not be the case.
Thanks for your response:
Running phpinfo() should tell you if its running as a module or cgi.
Yes. And easier is php_sapi_name() [or PHP_SAPI], which produces
apache2handler when I'm running php as a web server module. But it
shows me the same thing when php is started from the command line with
either php.exe vs. php-win.exe: cli. If I try try the same thing with
php-cgi, then I get: cgi-fcgi

So that's why the remaining problem is differentiating between php.exe
vs. php-win.exe
I believe it also has path information.

Sorry, I overlooked the part about php.exe and php-win.exe.

But why does it matter if its using the nix or the windows php
executable? IIRC, php can be invoked using php.exe on both windows and
*nix. Unless there is some very specific reason I don't know about?
I'm not concerned about *nix.
If you invoke php.exe and then do a print "whatever";
then you will get whatever output to the console window.

However, if you invoke php-win.exe and then do a print "whatever";
then you won't get anything since there is no console window. In other
words, while print might be sufficient with php.exe, it definitely
isn't with php-win.exe. Therefore, it makes sense to be able to
differentiate between them for some circumstances (so that an
alternative to print can be performed).

Csaba

Note: you could, of course, capture the output in both scenarios via
ob_start() and friends, but that is not the point.
If you're worried about differences between environment variables
because of the host OS, then check the OS environment variables and act
accordingly. If you see a X:\ in any of the paths, you can also know
if its windows or nix. same for the include_path directive (unix uses
:, windows uses ;).
Jul 9 '06 #8

P: n/a

Csaba Gabor wrote:
Richard Levasseur wrote:
Csaba Gabor wrote:
Richard Levasseur wrote:
Csaba Gabor wrote:
Is there a way to determine the path to the php executable (as opposed
to the script. In other words, I am looking for the path to php.exe or
php-win.exe) that is currently running (ie. how was this script called)
on Windows (I'm on Win XP Pro)? WScript/CScript (when programming in
VBScript) allow this, for example.
>
Failing that, is there any way to conclusively determine whether the
script that is running was invoked from php.exe or php-win.exe? I say
conclusively, because often there is a slight difference in the
environment variables, but it need not be the case.
>
Thanks for your response:
>
Running phpinfo() should tell you if its running as a module or cgi.
>
Yes. And easier is php_sapi_name() [or PHP_SAPI], which produces
apache2handler when I'm running php as a web server module. But it
shows me the same thing when php is started from the command line with
either php.exe vs. php-win.exe: cli. If I try try the same thing with
php-cgi, then I get: cgi-fcgi
>
So that's why the remaining problem is differentiating between php.exe
vs. php-win.exe
>
I believe it also has path information.
Sorry, I overlooked the part about php.exe and php-win.exe.

But why does it matter if its using the nix or the windows php
executable? IIRC, php can be invoked using php.exe on both windows and
*nix. Unless there is some very specific reason I don't know about?

I'm not concerned about *nix.
If you invoke php.exe and then do a print "whatever";
then you will get whatever output to the console window.

However, if you invoke php-win.exe and then do a print "whatever";
then you won't get anything since there is no console window. In other
words, while print might be sufficient with php.exe, it definitely
isn't with php-win.exe. Therefore, it makes sense to be able to
differentiate between them for some circumstances (so that an
alternative to print can be performed).

Csaba

Note: you could, of course, capture the output in both scenarios via
ob_start() and friends, but that is not the point.
If its being executed directly through one of the exe's, the
executable's name should be in argv[0]. That would let you get the
exe's real name. Not sure how true this is if its executed via the
webserver, though. I think the web server populates argv with get
parameters or something. If its being executed via the webserver, you
can probably assume print will work as intended.

I'm wondering what your final intent is? If you have a console window,
make html, otherwise make GUI widgets?
If you're worried about differences between environment variables
because of the host OS, then check the OS environment variables and act
accordingly. If you see a X:\ in any of the paths, you can also know
if its windows or nix. same for the include_path directive (unix uses
:, windows uses ;).
Jul 9 '06 #9

P: n/a
Richard Levasseur wrote:
Csaba Gabor wrote:
Richard Levasseur wrote:
Csaba Gabor wrote:
Richard Levasseur wrote:
Csaba Gabor wrote:
Is there a way to determine the path to the php executable (as opposed
to the script. In other words, I am looking for the path to php.exe or
php-win.exe) that is currently running (ie. how was this script called)
on Windows (I'm on Win XP Pro)? WScript/CScript (when programming in
VBScript) allow this, for example.

Failing that, is there any way to conclusively determine whether the
script that is running was invoked from php.exe or php-win.exe? I say
conclusively, because often there is a slight difference in the
environment variables, but it need not be the case.

Thanks for your response:

Running phpinfo() should tell you if its running as a module or cgi.

Yes. And easier is php_sapi_name() [or PHP_SAPI], which produces
apache2handler when I'm running php as a web server module. But it
shows me the same thing when php is started from the command line with
either php.exe vs. php-win.exe: cli. If I try try the same thing with
php-cgi, then I get: cgi-fcgi

So that's why the remaining problem is differentiating between php.exe
vs. php-win.exe

I believe it also has path information.
>
Sorry, I overlooked the part about php.exe and php-win.exe.
>
But why does it matter if its using the nix or the windows php
executable? IIRC, php can be invoked using php.exe on both windows and
*nix. Unless there is some very specific reason I don't know about?
I'm not concerned about *nix.
If you invoke php.exe and then do a print "whatever";
then you will get whatever output to the console window.

However, if you invoke php-win.exe and then do a print "whatever";
then you won't get anything since there is no console window. In other
words, while print might be sufficient with php.exe, it definitely
isn't with php-win.exe. Therefore, it makes sense to be able to
differentiate between them for some circumstances (so that an
alternative to print can be performed).

Csaba

Note: you could, of course, capture the output in both scenarios via
ob_start() and friends, but that is not the point.

If its being executed directly through one of the exe's, the
executable's name should be in argv[0]. That would let you get the
exe's real name.
I presume you are talking about WScript/CScript here because this
doesn't work with PHP. If you have delme.php:

<?php print 'argv[0]: ' . $GLOBALS["argv"][0]; ?>

and do:
php.exe delme.php

then you will get:
argv[0]: delme.php
Not sure how true this is if its executed via the
webserver, though. I think the web server populates argv with get
parameters or something. If its being executed via the webserver, you
can probably assume print will work as intended.
I'm wondering what your final intent is? If you have a console window,
make html, otherwise make GUI widgets?
Yes, I am doing CLI PHP applets. Now if I have php.exe in a console, I
can safely do print, knowing that the user has a fighting chance of
seeing it. However, if the script is invoked via php-win.exe (by
double clicking on it for explorer, for example), then doing a print
ensures that the user will never see the output (which is probably
undesireable in most situations).

The point is that it makes good sense to differentiate between the two
if I don't want to uniformly throw up a popup or other GUI.

Jul 10 '06 #10

P: n/a

Csaba Gabor wrote:
Richard Levasseur wrote:
Csaba Gabor wrote:
Richard Levasseur wrote:
Csaba Gabor wrote:
Richard Levasseur wrote:
Csaba Gabor wrote:
Is there a way to determine the path to the php executable (as opposed
to the script. In other words, I am looking for the path to php.exe or
php-win.exe) that is currently running (ie. how was this script called)
on Windows (I'm on Win XP Pro)? WScript/CScript (when programming in
VBScript) allow this, for example.
>
Failing that, is there any way to conclusively determine whether the
script that is running was invoked from php.exe or php-win.exe? I say
conclusively, because often there is a slight difference in the
environment variables, but it need not be the case.
>
Thanks for your response:
>
Running phpinfo() should tell you if its running as a module or cgi.
>
Yes. And easier is php_sapi_name() [or PHP_SAPI], which produces
apache2handler when I'm running php as a web server module. But it
shows me the same thing when php is started from the command line with
either php.exe vs. php-win.exe: cli. If I try try the same thing with
php-cgi, then I get: cgi-fcgi
>
So that's why the remaining problem is differentiating between php.exe
vs. php-win.exe
>
I believe it also has path information.

Sorry, I overlooked the part about php.exe and php-win.exe.

But why does it matter if its using the nix or the windows php
executable? IIRC, php can be invoked using php.exe on both windows and
*nix. Unless there is some very specific reason I don't know about?
>
I'm not concerned about *nix.
If you invoke php.exe and then do a print "whatever";
then you will get whatever output to the console window.
>
However, if you invoke php-win.exe and then do a print "whatever";
then you won't get anything since there is no console window. In other
words, while print might be sufficient with php.exe, it definitely
isn't with php-win.exe. Therefore, it makes sense to be able to
differentiate between them for some circumstances (so that an
alternative to print can be performed).
>
Csaba
>
Note: you could, of course, capture the output in both scenarios via
ob_start() and friends, but that is not the point.
>
If its being executed directly through one of the exe's, the
executable's name should be in argv[0]. That would let you get the
exe's real name.

I presume you are talking about WScript/CScript here because this
doesn't work with PHP. If you have delme.php:

<?php print 'argv[0]: ' . $GLOBALS["argv"][0]; ?>

and do:
php.exe delme.php

then you will get:
argv[0]: delme.php
Not sure how true this is if its executed via the
webserver, though. I think the web server populates argv with get
parameters or something. If its being executed via the webserver, you
can probably assume print will work as intended.
I'm wondering what your final intent is? If you have a console window,
make html, otherwise make GUI widgets?

Yes, I am doing CLI PHP applets. Now if I have php.exe in a console, I
can safely do print, knowing that the user has a fighting chance of
seeing it. However, if the script is invoked via php-win.exe (by
double clicking on it for explorer, for example), then doing a print
ensures that the user will never see the output (which is probably
undesireable in most situations).

The point is that it makes good sense to differentiate between the two
if I don't want to uniformly throw up a popup or other GUI.
It would seem you're out of luck, then, at least for windows. In *nix
you might be able to use the "_" env variable. You can always require
a command line switch to be set to specify the mode. The only other
idea i have is to figure out where stdout is going.

Jul 10 '06 #11

P: n/a
Richard Levasseur wrote:
It would seem you're out of luck, then, at least for windows. In *nix
you might be able to use the "_" env variable. You can always require
a command line switch to be set to specify the mode. The only other
idea i have is to figure out where stdout is going.
Hmmm, that should work. GUI apps on Windows have null stdout. An
attempt to write to it would fail:

$stdout = fopen("php://stdout", "wb");

if(@fwrite($stdout, "Error: the dingo ate my baby\n") == 0) {
// do something else
}

Jul 10 '06 #12

P: n/a
On 10 Jul 2006 13:25:00 -0700, "Chung Leong" <ch***********@hotmail.comwrote:
>Richard Levasseur wrote:
>It would seem you're out of luck, then, at least for windows. In *nix
you might be able to use the "_" env variable. You can always require
a command line switch to be set to specify the mode. The only other
idea i have is to figure out where stdout is going.

Hmmm, that should work. GUI apps on Windows have null stdout. An
attempt to write to it would fail:

$stdout = fopen("php://stdout", "wb");

if(@fwrite($stdout, "Error: the dingo ate my baby\n") == 0) {
// do something else
}
Unfortunately not; stdout is still writable, but it's just discarded - similar
to redirecting to /dev/null on Unix.

C:\tmp>type dingo.php
<?php
$stdout = fopen("php://stdout", "wb");
$fp = fopen("out.txt", "wb");

fwrite($fp, $stdout . "\n");

if(@fwrite($stdout, "Error: the dingo ate my baby\n") == 0) {
fwrite("out.txt", "error branch\n");
// do something else
}
?>

C:\tmp>php-win.exe dingo.php

C:\tmp>type out.txt
Resource id #5

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Jul 10 '06 #13

P: n/a
Andy Hassall wrote:
On 10 Jul 2006 13:25:00 -0700, "Chung Leong" <ch***********@hotmail.comwrote:
Unfortunately not; stdout is still writable, but it's just discarded - similar
to redirecting to /dev/null on Unix.
No, having the handles of stdout being null is different from the
stdout redirected to to null. Double check your code.

Jul 10 '06 #14

P: n/a
On 10 Jul 2006 14:45:30 -0700, "Chung Leong" <ch***********@hotmail.comwrote:
>Andy Hassall wrote:
>On 10 Jul 2006 13:25:00 -0700, "Chung Leong" <ch***********@hotmail.comwrote:
Unfortunately not; stdout is still writable, but it's just discarded - similar
to redirecting to /dev/null on Unix.

No, having the handles of stdout being null is different from the
stdout redirected to to null. Double check your code.
Which part? The previous code behaves identically when run through php.exe and
php-win.exe (other than what is actually seen coming out of stdout). What am I
missing?

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Jul 10 '06 #15

P: n/a

Andy Hassall wrote:
On 10 Jul 2006 14:45:30 -0700, "Chung Leong" <ch***********@hotmail.comwrote:
Andy Hassall wrote:
On 10 Jul 2006 13:25:00 -0700, "Chung Leong" <ch***********@hotmail.comwrote:
Unfortunately not; stdout is still writable, but it's just discarded - similar
to redirecting to /dev/null on Unix.
No, having the handles of stdout being null is different from the
stdout redirected to to null. Double check your code.

Which part? The previous code behaves identically when run through php.exe and
php-win.exe (other than what is actually seen coming out of stdout). What am I
missing?
This line: fwrite("out.txt", "error branch\n");

I hate it when it happens too ;-)

Jul 10 '06 #16

P: n/a
On 10 Jul 2006 15:03:19 -0700, "Chung Leong" <ch***********@hotmail.comwrote:
>Andy Hassall wrote:
>On 10 Jul 2006 14:45:30 -0700, "Chung Leong" <ch***********@hotmail.comwrote:
>Andy Hassall wrote:
On 10 Jul 2006 13:25:00 -0700, "Chung Leong" <ch***********@hotmail.comwrote:
Unfortunately not; stdout is still writable, but it's just discarded - similar
to redirecting to /dev/null on Unix.

No, having the handles of stdout being null is different from the
stdout redirected to to null. Double check your code.

Which part? The previous code behaves identically when run through php.exe and
php-win.exe (other than what is actually seen coming out of stdout). What am I
missing?

This line: fwrite("out.txt", "error branch\n");

I hate it when it happens too ;-)
Argh! Yes you're quite right - sorry.

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Jul 10 '06 #17

P: n/a
Chung Leong wrote:
Richard Levasseur wrote:
It would seem you're out of luck, then, at least for windows. In *nix
you might be able to use the "_" env variable. You can always require
a command line switch to be set to specify the mode. The only other
idea i have is to figure out where stdout is going.

Hmmm, that should work. GUI apps on Windows have null stdout. An
attempt to write to it would fail:

$stdout = fopen("php://stdout", "wb");

if(@fwrite($stdout, "Error: the dingo ate my baby\n") == 0) {
// do something else
}
thank you, Thank You, THANK YOU
Hey Chung, majorly cool!

<?php
$stdout = fopen("php://stdout", "wb");
if(@fwrite($stdout, " \x08") == 0) {
// php-win
} else {
// some other invocation
}
?>

Thanks again,
Csaba

Jul 11 '06 #18

This discussion thread is closed

Replies have been disabled for this discussion.