On Thu, 2002-05-02 at 21:18, Shane Caraveo wrote: > Zeev Suraski wrote: > > Does anybody have an opinion about this? > > Of course! ;) > > ini search order > 1. PHP_BIN_DIR (\php\) > 2. OS_DIR (\winnt\) > > To fix the ini issue we need more than just this. The best I can come > up with right now is: > > 1. implement bang line parsing. This way, a specific script can define > what ini file it wants to use. It should only be available in CGI/CLI > systems. > > 2. add support for -c to use filenames in addition to paths. This way > a single directory can contain multiple different config files. > > 3. have sapi modules (dll's) detect their directory so that server > modules can correctly define where the ini file is for a particular > installation. > > 4. For web servers, allow ini filenames to be php-domain.com.ini (or > something like that) and have sapi modules look for that first if > SERVER_NAME is available. > > 5. Implement 'override' ini files, which basicly behave the same as > .htaccess. Use of these is settable in the 'global' ini file. They > exist in the same directory as the script itself, and are read > recursivly through the parent directory structure to some root (web > root). This of course would be cached in persistent systems, CGI/CLI > users would probably not want to use this feature. > > Some of the above will rely on the OS security being configured > correctly so that people cannot access each other's ini files, but that > is not the responsibility of PHP to handle (though it could be > documented to some extent).
I think we should add: 6. Implement "include_ini" directive 7. Look for php-<SAPI>.ini first, and php.ini if not found (this may double the disk activity, if that's acceptable). - Stig -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
