On UNIX-like systems, PHP (with
back-ends other than CLI) looks for php.ini in /usr/local/lib by default. To be
more “shell-ish,” the CLI back-end looks for /etc/php-cli.ini by default, instead.
This makes it possible to keep separate php.ini files for your web server and
CLI/shell scripts, without having to specify the ­c option every time you run a
PHP-driven script.
Different UNIX/Linux distributions that bundle PHP often use their own
default php.ini location; you can find the file used by your PHP executable
with get_cfg_var(”cfg_file_path”).

Other Differences
When PHP is running inside a web server, func-
tionality, such as fork() makes little sense, because it would duplicate the
entire web-server process and not just PHP. This is bad because the web
server process contains lots of code that is completely unrelated to PHP, possi-
bly including other web-scripting modules, such as mod_perl. In a threaded
environment, it would even duplicate all the threads in that process. If the
purpose of your fork is to exec another program right away, this does not mat-
ter. But if you want to fork to keep running PHP code in the new process, hav-
ing this extra baggage in the process can be really bad.
For this reason, PHP’s process control extension (pcntl) is only available
in the CLI version, where a fork() call only makes a duplicate of PHP.