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). Shane -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
