|
|
Posted by Csaba Gabor on 12/17/16 11:52
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 ;).
Navigation:
[Reply to this message]
|