I'm running IIS 6.0.
Is it possible to set the interpreter path (somewhat like the PHP shebang line) in a PHP File rather in the config-file?
Example:
Let's say I have two version installed (PHP4 and PHP5) the default is set to PHP4. Can I set the files individually to use another interpreter (in that case PHP5) than the default one?
I don't know about IIS, but this is usually handled in Apache-land using mod_php for one one version, and fast-cgi mode for the other, and then setting the handler for php files in a .htaccess file (if you need granular control)
How about different file extensions, like php4 and php for the current version. That should be no problem. Never did it, but that can be configured for sure, b/c your server-application then can decide which interpreter to invoke.
Related
I'm using PHP 7.2.10 on my laptop that runs on Windows 10 Home Single Language 64-bit operating system.
I've installed Apache/2.4.34 (Win32) and PHP 7.2.10 using the latest version of XAMPP.
Today, I come across the following statement from PHP Manual :
The configuration file (php.ini) is read when PHP starts up. For the
server module versions of PHP, this happens only once when the web
server is started. For the CGI and CLI versions, it happens on every
invocation.
Above text has created following doubts in my mind :
What does exactly mean by first sentence? It's only saying that
The configuration file (php.ini) is read when PHP starts up.
But it's not saying who does read it? Is it the PHP parser or the Apache web server? Or something else? Please explain to me.
In case of CGI and CLI versions, why the php.ini file is read again and again and who reads it?
In case of CGI and CLI versions, the process of reading the php.ini file happens on every invocation? What does mean by this sub-clause every invocation?
How many php.ini files can possibly be exist there? If such more than one files exist then what's the role of every such php.ini file?
P.S. : All the above questions have been asked to me in a technical interview.
P.S. : I know that php.ini is the main configuration file with all the configuration setting on the local machine.
The PHP compiler/parser.
Because PHP does not persist for command line invocations, so it is read at run-time.
Every time you call a PHP script, either CGI or CLI.
More than one, typically 2. One for the web server and one for CLI/CGI.
I am using php version 5.3 on media temple's grid server, however when I call a file using exec() the page is executing in PHP version: 4.4.9
The reason I am using exec() is to process the file in the background.
This is probably a simple question, but how do I manually set the PHP version to 5.3 for this file without using .htaccess?
Thanks.
The PHP interpreter you invoke via exec() is often a CGI version installed on the server as /usr/bin/php. You need to find out if a more contemporary version is available and then call the interpreter explicitly:
exec("/usr/bin/php-5.3 your-script.php &");
# or just adapt your scripts shebang #!/usr/bin/php5
(Just an example, the filename will be different. Also you can usually leave out the path. It's mostly just security relevant for setuid binaries.)
You might find out about other versions via print_r(glob("/usr/bin/php*")). But asking your hoster might be a better idea.
I am running PHP on Windows. PHP plugins on Windows are just DLL's in an extensions folder, and I can do little to configure these plugins.
For example, the ADAP plugin (which is OpenLDAP itself) has settings that I can't change on runtime. Luckily, OpenLDAP allows me to change some of these settings by messing with the environment variables. I tried setting them up on runtime by adding both:
// this apparently works on Linux
putenv('VARIABLE=value');
// tried this one as well
$_ENV['VARIABLE'] = 'value';
But that didn't work. I had to add that to Windows' environment variables (and that did work), but that's too much of a pain in the rear and will break the code when I move it. Is there a better way to do this or I'll have just to deal with it?
Thanks
Try to set the environment variables before the dll extension is loaded. That is, don't load the dll via php.ini, but use putenv() and afterwards dl(). Usually a DLL should share the environment variables with the main process, but you never know.
Alternatively set any required options from within .htaccess using SetEnv. This is at least portable for Apache webservers. Come to think of it, you should also try apache_setenv() if you are running mod_php and not the FastCGI version.
Btw, there have always been PHP bugs for putenv, http://bugs.php.net/50690, might be the case here.
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.
I need to install or use php on a windows 2003 server that already has php 5.2.0.0 installed due (I think) to setting up symantec backup exec. I don't want to interfere with backup exec's php.ini settings - and would rather be able to control my own configuration of php.
searching for php shows that php.exe and other php files are currently installed in
c:\program files\symantec\backup exec\
I'm almost certain that installing the current version of php 5.2.8 to c:\php would be disastrous or calamitous in some way.
There is no PHPRC entry in the server properties > environment variables and I'm pretty sure that the php.exe location is not included in the PATH variable. ...unless the actuall install location is different from the c:\program files\symantec\backup exec\ dir.
Any suggestions on how to proceed?
I'm almost certain that installing the current version of php 5.2.8 to c:\php would be disastrous or calamitous in some way.
What makes you say that :) I've run separate PHP versions on the same machine side by side and not run into bother.
AFAIK the Symantec install should not conflict with your own installation, nor should the separate php.ini files conflict with each other.
[Response to comment]
First thing to note is that I have no experience of Backup Exec or what it uses PHP for. I'm guessing it uses it for its own internal stuff and doesn't spread itself over the OS. Test this by searching for php.ini and php DLLs on the file system. I'm betting it's all quite self contained. PHP searches for the config file as noted here: PHP Site . As you note, BE hasn't set the PHPRC variable. Check it hasn't used those Registry entries either. On a different tack, has BE installed an admin site already on IIS? If so, check the IIS Web Service Extensions to make sure it hasn't already registered the PHP ISAPI dll or PHP CGI exe. IF not, I think you should be okay for your new install.
To be on the safe side, do a manual PHP install as illustrated here: PHP Site. That way, you know exactly what you have installed, and can easily remove the files again if they cause a problem. I can't imagine a problem here that would require you to reinstall BE.