Which PHP am I running?

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.

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
}

On 10 Jul 2006 13:25:00 -0700, "Chung Leong" <chernyshevsky@hotmail.com> 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
>}

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 :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

Andy Hassall wrote:
> On 10 Jul 2006 13:25:00 -0700, "Chung Leong" <chernyshevsky@hotmail.com> wrote:
> 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.

On 10 Jul 2006 14:45:30 -0700, "Chung Leong" <chernyshevsky@hotmail.com> wrote:

>Andy Hassall wrote:
>> On 10 Jul 2006 13:25:00 -0700, "Chung Leong" <chernyshevsky@hotmail.com> wrote:
>> 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 :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

Andy Hassall wrote:
> On 10 Jul 2006 14:45:30 -0700, "Chung Leong" <chernyshevsky@hotmail.com> wrote:
>
> >Andy Hassall wrote:
> >> On 10 Jul 2006 13:25:00 -0700, "Chung Leong" <chernyshevsky@hotmail.com> wrote:
> >> 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 ;-)

On 10 Jul 2006 15:03:19 -0700, "Chung Leong" <chernyshevsky@hotmail.com> wrote:

>Andy Hassall wrote:
>> On 10 Jul 2006 14:45:30 -0700, "Chung Leong" <chernyshevsky@hotmail.com> wrote:
>>
>> >Andy Hassall wrote:
>> >> On 10 Jul 2006 13:25:00 -0700, "Chung Leong" <chernyshevsky@hotmail.com> wrote:
>> >> 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 :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

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