I'm using Windows 10 Home Single Language 64-bit Operating System on my laptop.
I've installed the latest version of XAMPP on my laptop.
This has installed PHP 7.2.8 and Apache/2.4.34 (Win32) OpenSSL/1.1.0h PHP/7.2.8 on my laptop.
I come across following sentence from PHP Manual Page :
PHP can be used on all major operating systems, including Linux, many
Unix variants (including HP-UX, Solaris and OpenBSD), Microsoft
Windows, macOS, RISC OS, and probably others. PHP also has support for
most of the web servers today. This includes Apache, IIS, and many
others. And this includes any web server that can utilize the FastCGI
PHP binary, like lighttpd and nginx.
From the above text I didn't get the exact meaning of the term "PHP binary". This peculiar term is used very frequently at many places in the PHP Manual but nowhere the actual meaning of "PHP binary" has been given.
I googled it for the meaning and I come to know about the 'predefined constant' PHP_BINARY.
So, I tried to execute the below code in hope to clear my doubt over the actual meaning of the frequently used term "PHP binary" and checked the output in my web browser:
<?php
echo PHP_BINARY;
?>
Surprisingly, I got the below output :
C:\xampp\apache\bin\httpd.exe
I got surprised to see this output because in output I got complete address of the Apache file httpd.exe. I was expecting to get something about PHP but I got Apache file's address. Why so?
So, what does ultimately mean is I still don't understand what does actually mean by the frequently used term "PHP binary"?
I still don't have any idea about what does actually mean by the very frequently used term "PHP binary"?
Someone, please clear my doubt about the frequently used term "PHP binary" in an easy to understand, simple and lucid language.
I'm waiting for your help.
The compiled version of any program is commonly referred to as it's "binary".
PHP has multiple binaries for multiple purposes.
php.exe is used to run scripts locally in your Command Prompt;
php-cgi.exe is compliant with FastCGI protocol;
php7apache2_4.dll is PHP wrapped as an Apache 2.4 module;
And a few others too.
In this case the docs are referring to php-cgi.exe
The constant PHP_BINARY contains the path of the binary where PHP is currently executing from. Since XAMPP uses Apache, and Apache is most likely using PHP in it's Apache module form, it makes sense that httpd.exe is recognized as the binary, since it is loading php7apache2_4.dll.
PHP itself is running as a program on your computer (often referred to a binary).
Supposed we were on Windows, the PHP binary would probably be php.exe. Essentially, PHP itself.
Note that the PHP binary could be a server module... a DLL or similar.
Related
I come across following statement from PHP Manual
PHP source code and binary distributions for Windows can be found at »
http://www.php.net/downloads.php. We recommend you to choose a »
mirror nearest to you for downloading the distributions.
This statement has created following doubts in my mind :
What does actually mean by 'PHP binary distributions for Windows'?
Why there are no such 'PHP binary distributions' for other operating systems like Linux, Mac OS X, RISC OS, and others?
I've installed PHP 7.2.3 on my machine running on Windows 10 operating system with the latest copy of XAMPP package then have I installed the 'PHP binary distributions for Windows'?
What's the use/need/necessity/benefit/advantage of the 'PHP binary distributions for Windows'?
Are the 'PHP binary distributions for Windows' available for download only on official PHP website?
How the 'PHP binary distributions for Windows' is different from PHP source code with reference to the above statement from PHP Manual?
Someone please clear all of my above doubts in an easy to understand language.
A binary distribution is an executable program for an operating system like Windows. Different operating systems and different prozessors need different approaches to run programs. Thus there are different distributions, that are generated differently.
see 1.
It depends on the xampp version, but yes the latest xampp does have version 7.2.3 of php (you don't need to install it again if as long as you are working in the xampp environment)
You need it to develop php code on you local machine. There are other ways, which might be a bit more complex for your level of knowledge. The binaries work mostly out of the box, more or less.
There are others, like in the xampp package, but the php website is generally the best source for it.
Source code is the program code from which the binaries are build. You can not use it as is.
Is there a way to set the process title for a PHP script running under Apache (mod_php)? Typically, if I look at the output of top, I just see a bunch of copies of apache2, which is not usefull. I am using Ubuntu Linux in case that matters.
I have found the PECL proctitle extension, but it seems that it doesn't work very well. Plus, it's an extension, meaning I would have to get it installed, etc. I would prefer another way.
I also found the cli_set_process_title function, which seems to do what I want, but it only works in CLI mode. Is there an Apache version of this function?
This only occurs on IIS 7.5 server on Windows 7 (on linux decimal point is set just fine).
$locale = setlocale(LC_ALL, 'pl_PL.utf8', 'pl_PL', 'pl', 'polish');
echo $locale;
echo strftime('%B');
print_r(localeconv());
Output:
Polish_Poland.1250
grudzień
Array (
[decimal_point] => .
...
)
As you can see:
Locale are set ok
Month prints just fine
Decimal point is . while it should be ,
PHP is VC9 TS running as FastCGI module, tried running from CLI with the same result...
Any idea why and if there is a fix?
If this is happening at the CLI level, then I'd say this is a bug in PHP and should be reported (http://bugs.php.net).
Before you do, however, you should take the following steps so they won't yell at you:
Make sure you're running the latest stable version of PHP (5.3.8)!! They'll ask you for the version, and if you're using an older one, they'll probably just mark it bogus and tell you to download the current version.
Repeat the test in Linux using the identical script. The result will tell you whether the bug is specific to the Windows build or not. If it is, it may or may not be a problem with Windows itself (in which case Pierre might get a bit annoyed), but I'd say it's still worth posting so that there's a record of this issue on the bug tracker.
This isn't required, but converting your script to a PHPT file and then posting that might get you a more prompt response.
If possible, try replicating this bug on a separate Windows box so that a problem with your OS configuration can be ruled-out. You can of course skip this step if the bug occurs in Linux as well.
Once the bug is posted, please post a link to it here. You'll probably get responses asking for additional information, so keep an eye on it and be prepared to do so without too much delay.
This process will confirm whether or not it's a bug in PHP. If it is a bug, then your report will lead to a fix in the next release. If a hotfix is posted, I could patch that into the source and send you a custom build to use until the next version is released.
Oh and on an unrelated note, you should not be using the ZTS build of PHP on IIS/FastCGI! I don't think this is related to the problem you're having, but you could run into other problems (performance decline, random crashes, etc) if you continue using that build. What you want is the NTS (non-thread-safe) build.
Here's the basic rule of thumb for running PHP on Windows:
Apache: Thread-safe (ZTS)
IIS ISAPI: Thread-safe (ZTS)
IIS FastCGI: Non-thread-safe (NTS)
In http://windows.php.net/downloads I couldn't find any x64 built for download.
Further I have to choose among "Thread Safe" and "Non Thread Safe" with no explanation whether one is safer than the other or it performs better. The install.txt inside the available ZIPs for download seems out-dated an it doesn't mention anything about this.
In http://php.net/manual/pl/install.windows.iis7.php they don't say a word about it either...
Another doubt is once I know what to download (and why), should it be setup as a FastCGI module or as an ISAPI extension?
(My experiences running PHP under IIS)
I believe that you should set up PHP as a FastCGI module - I don't think you are able to set up PHP as an ISAPI extension. You can set up PHP either using FastCGI or ISAPI - It may be that ISAPI is faster than FastCGI. There is a guide on setting up IIS using ISAPI here:
http://www.lazynetworkadmin.com/knowledgebase-mainmenu-6/2-windows/141-install-php-on-server-2008-r2
Searching google reveals a lot of pages discussing the thread safe vs non thread safe argument if you want to know the detail, however the short version is that the non thread safe version is faster, but the thread safe version is safer. You should choose the thread safe version for now unless you have a performance problem and know that your app is going to run correctly under the non thread safe binaries.
Finally, there isn't really any need for x64 binaries when running PHP as a FastCGI application - php runs as a separate process and so the x86 binaries will run fine on a x64 web server, and most normal php applications will have no need for an address space above 4GB as to scale IIS can simply start additional php processes.
When configuring your FastCGI extension you need to point it at the php-cgi.exe executable in the php installation directory.
I often use FastCGI when setting up PHP on IIS. It is moreso habit than anything else. While I did read over many of the other articles posted and it does appear that ISAPI has many advantages I thought I'd add a link to setting up FastCGI for those who want to go that route. I've used it and never had any issues with moderate request traffic.
Anyway here's a link to an article with screenshots on setting up PHP via FastCGI on IIS 7.5.
Click here to visit the article.
From inside a PHP program I want to know the location of the binary executing it. Perl has $^X for this purpose. Is there an equivalent in PHP?
This is so it can execute a child PHP process using itself (rather than hard code a path or assume "php" is correct).
UPDATE
I'm using lighttpd + FastCGI, not Apache + mod_php. So yes, there is a PHP binary.
eval/include is not a solution because I'm spawning a server which has to live on beyond the request.
Things I've tried and don't work:
$_SERVER['_'] looks like what I want from the command line but its actually from an environment variable set by the shell of the last executed program. When run from a web server this is the web server binary.
which php will not work because the PHP binary is not guaranteed to be the same one as is in the web server's PATH.
Thanks in advance.
The PHP_BINDIR constant gives you the directory where the php binary is
Yeah, $_SERVER['_'] is what you're talking about, or as near as exists. The reason you're getting a Web server binary when it's run from the web is that /usr/bin/php has nothing to do with the Web server's execution; what it's running is a separate SAPI. There's nothing from the web PHP instance to point to /usr/bin/php because there's no reason for there to be.
The PHP_BINDIR constant is probably the easiest thing to use; the next best thing I could come up with is basically re-creating that bindir path from the extension_dir configuration setting:
$phpbin = preg_replace("#/lib(64)?/.*$#", "/bin/php", ini_get("extension_dir"));
It has a regex in it, so it feels more like your native perl(!) but otherwise is not especially optimal.
In PHP5.4 you can use the PHP_BINARY constant, it won't work via mod_php or similar but will via CGI etc.
For earlier versions of PHP readlink('/proc/self/exe'); will probably be fine, again it won't work via mod_php.
Depending on the way php is installed you CANT find the php executable.
if php is running as a module for the webserver like apache module, then there is no binary you can call.
you can take a look into php_info() it lists everything.
may also the path to php. within that path you can assume a php binary.
but why do you want to call a extra process?
you can execute other php files by include command or eval.
there is no reason to spawn a new process.
what about:
<?php
exec("which php");
?>
But, it's unix/linux only:D
I've been looking for the php7 executable on my mac (OSX El Capitan) in order to configure and install xdebug (needed to find the right version of phpize to run). None of the solutions I found worked for me, so I just ended out searching for it:
find / -name php -print
I knew (from phpinfo()) that I was running php7, so I was able to infer the correct directory from the options presented by find.