Search on DDG and in here didn't get any interesting results. I've heard they're different, but I want to know what makes them different and what advantage is there in having two different configurations ?
EDIT : Yes, I am running them both from the CLI.
phpinfo() is a language function that will display its output regardless of whether the script that it's executed in is called through the web SAPI or from CLI;
php -i is purely a command line switch to get information about PHP from the command line.
Why different configurations for web sapi and for CLI? Because you might have different requirements; often devs will run long command line scripts and don't want the web sapi timeout applied, similarly with memory settings; and max file/post size ini settings are meaningless for CLI, so why bother having them in the cli ini file when they're only needed for the web?
Depending on your server distribution, there may be separate php.ini
files for the command line and web server.
Source:
Pro PHP
Patterns, Frameworks, Testing and More
By Kevin McArthur
https://books.google.pl/books?id=CpUhDavmgSMC&pg=PT410&lpg=PT410&dq=%22php+-i+command%22&source=bl&ots=iljmNZ96ZU&sig=iRrX8_UjJWiOzlLtRz0zwJOtQJc&hl=pl&sa=X&ved=0ahUKEwicoq6NrsLLAhVjQZoKHeSSA8wQ6AEIPDAE#v=onepage&q=%22php%20-i%22&f=false
php -i gives you the same info you got using phpinfo() but:
can use a different set of INI files than your web server (so you can different values for some configuration parameters)
it formats the data in a console-friendly way (no html tags, for example)
Edit:
don't digged the sources, but I can bet both uses the same code to extract their info .. in other words php -i is "calling phpinfo()" in a console-aware way and context
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 created a basic web server in Java. It can also run php code.
I execute:
php - f <file>
to get the result and send it back to the client. It works great, however when I want to use the phpinfo(); function, it returns plain text as it is written in the manual too. How can I get the result in HTML format like Apache does?
Thank you!
I'm afraid that's hardcoded in PHP's binary. It detects if it's running an Apache module or the CLI binary. Since you're not invoking the Apache module, it uses the CLI one. From the manual page:
phpinfo() outputs plain text instead of HTML when using the CLI mode.
You might want to try running the file through the php-cgi interface instead (should be an executable named php-cgi or similar).. this is one of the ways you can run php under apache.. (other choice being mod php or fcgi)
Raidence, why would you make a http server with dependencies to apache, you dont get the redundancy in that?
I run some PHP websites on a FreeBSD server which was recently updated to PHP 5.2.17, after which exec("something") stopped working, and I was required to write exec("/full/path/something").
Since the scripts run on different machines where executables are in different places writing full paths is not acceptable.
Running passthru("set") from PHP reveals the PATH variable (for user "www") to be:
PATH=/sbin:/bin:/usr/sbin:/usr/bin
I need PATH to point to the PHP safe_mode_exec_dir directory:
PATH=/usr/phpsafe_bin
Running putenv("PATH=/usr/phpsafe_bin") in PHP resolves the problem, but I need a solution that fixes the problem on a global level for all PHP scripts running on this machine, in other words changing php.ini, Apache settings, or other system settings.
Hope someone can provide a good solution to this, maybe even an explanation why this changed in the PHP update. There seems to be no PHP documentation on how the search path for exec() and friends is determined.
It's not a pleasant solution, but it's all I could think of. Create a script file that does the change you've suggested and then use the "auto_prepend_file" in php.ini or .htaccess to include this script. Then in effect every php script that is run will have this file run before it gets executed and thus your directory is changed.
Caution: You need to be very careful using this since any errors, extra white space etc in the prepend script can break whole pages, existing features such as download scripts, or any number of unknown effects.
Read More: http://php.net/manual/en/ini.core.php
I have a (possibly dumb) question.
I have a script made in php, constructed for cli usage. Works fine when I run it from the command line, no problem there. The problem is that the site I'm working on has ssh restrictions on the hosting server and I cannot ssh there to run it. Hence my question: how can I run the script from another php that is web-accessible? Already tried with exec(), system(), etc.
The main problem is that I need he $_SERVER['SHELL'] variable set, and when the call is comming from a web browser of course php doesn't set it.
Any ideeas will be greatly apreciated, thanx.
There are many possibilities why exec() and related function calls are not working for you.
Your webhost does not have PHP-CLI installed. Just a webserver module
You need to use the full path to the php binary for lack of a decent shell environment. E.g. /usr/bin/php <script> instead of php <script>.
Your webhost has installed PHP-CLI on a non-standard path (e.g. /usr/local/bin/php, or /opt/php5/php)
The webserver user does not have rights to access the php binary
Et cetera..
maybe update the php script to be both an include and a cli script.
use
__FILE__
to check if it's a file, then read the params. otherwise do nothing.
and as an include just call the function you want directly.
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.