Re: Does PECL install modify my php.ini? or even look at it?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 16, 2006 4:07 pm, D. Dante Lorenso wrote:
> Richard Lynch wrote:
>> On Tue, May 16, 2006 10:34 am, D. Dante Lorenso wrote:
>>
>>> Richard Lynch wrote:
>>>
>>>> On Thu, May 11, 2006 6:02 pm, D. Dante Lorenso wrote:
>>>>>    > pecl install memcache
>>>> s it possible that pecl has an --extension-dir flag to tell it
>>>> WHERE
>>>> to install stuff, or perhaps an optional command line arg or ...
>>>> Cuz, really, the odds on it being where you want it to be are
>>>> pretty
>>>> slim.
>>> Odds would be increased if 'pecl' would look at what I've already
>>> declared in the PHP.ini file ;-)
>>>
>> Okay, then you need to add a parameter to the command line to tell
>> pecl where your php.ini file is, because it is *NOT* going to be in
>> the place pecl "thinks" it will be on many many many machines.
>>
> /usr/bin/php knows where the php.ini file is and /usr/bin/pecl is
> written
> in PHP.  It boils down to an ini_get() call.  Sounds like your fear of
> not knowing where the php.ini file is located is already alleviated.

/usr/bin/php might know where the php.ini file which was compiled into
the CLI php lives, but that could easily have nothing to do with where
the HTTP php.ini lives, since one may have quite different php.ini for
those two scenarios of CLI and HTTP

The security needs alone of HTTP versus CGI versus CLI are quite
different.

For that matter, in more recent versions, the compiled-in value for
CLI could match the compiled-in value for HTTP, and it STILL could be
wrong because there is an Apache directive to tell PHP where to look
for php.ini which overrides the compiled-in default under HTTP.

Not to mention that I could easily, and, in point of fact, DO HAVE,
mutliple php.ini files for use with CLI php for various circumstances,
none of which match up with the php.ini used for HTTP.

And it's entirely possible that I would want to install my new pecl
module only in a particular installation of PHP.

Did I mention that I also need to run one version of PHP from a
snapshot which needs yet another php.ini because of a patch?

Oh, and also, it's perfectly common for the CLI php install to have no
php.ini file at all, and to be running from the "default defaults"
(sic) which (used to ?) match the php.ini-dist settings if you didn't
copy php.ini-dist as instructed in the install documentation.

It's also not uncommon for the HTTP install to not have an actual
php.ini file, for that matter.

If you think all of this doesn't matter, or only applies to experts,
you've clearly not been through the joy of the "Great php.ini Hunt"
with an inexperienced user, not to mention dealt with Windows/IIS
where you're pretty much STUCK with whatever php.ini value was
randomly-selected [1] by the Windows release bundler person, and which
could easily not match the one bundled into the first php.exe
encountered in the MS-DOS shell $PATH variable, if they've ever
re-installed PHP.

[1] I exaggerate.  It's not randomly-selected.  It's just very very
very inconsistent and depends entirely on who felt like compiling the
Windows archive this day/week/month/year/version.  The effect,
however, is about the same as it being random, since it could easily
be any one of:
C:\php
C:\php4
C:\php5
C:\Windows\System\
C:\Windows\System32\
.
.
.

-- 
Like Music?
http://l-i-e.com/artists.htm

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux