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
