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