Which PHP am I running?

[Csaba Gabor]

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

[Richard Levasseur]

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

[Csaba Gabor]

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

[Chung Leong]

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.

[Csaba Gabor]

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.

[Chung Leong]

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.

[Richard Levasseur]

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 ;).

[Csaba Gabor]

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 ;).

[Richard Levasseur]

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 ;).

[Csaba Gabor]

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.

[Richard Levasseur]

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.

[Chung Leong]

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
}

[Andy Hassall]

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

[Chung Leong]

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.

[Andy Hassall]

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

[Chung Leong]

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 ;-)

[Andy Hassall]

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

[Csaba Gabor]

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