Re: dirname(__FILE__)

I was thinking along the lines of require_once @PEAR. 'PEAR.php' on this principle - if you have set up pear 'as currently' in you include class, there is no need to define PEAR, otherwise, if you are using it in your application define('PEAR', '/path/to/my/pear'); However! Trouble is that this makes it more difficult to say 'use the core pear packages from /usr/share/pear' and use local packages eg. /home/me/pear/ at the same time. Is there some bit problem on using ini set, as mentioned below: either that or why not automate it inside PEAR.php if (!preg_match('/;' . dirname(__FILE__) . ';/')) { ini_set('include_path',ini_get('include_path').SEPERATOR.dirname(__FILE__)); } or similar , and say if you cant change your php.ini, just require_once /wherever/my/pear/PEAR.php and all the paths will be sorted out. Regards Alan Andrew Braund wrote:

I don't have access to php.ini on some of the servers I use but have found that if I install pear in 'includes' off my home directory and use the following at the top of any of my scripts that use PEAR it works OK; $incPath = ini_get('include_path'); ini_set('include_path',$incPath.':/home/abraund/includes:/home/abraund/includes/p ear'); The servers I use allow me to change include_path. I don't know if most hosting companies disable this but the two I use don't so it works for me. Regards Andrew Braund

On Wed Oct 16, 2002 at 07:3322PM +0200, Stig S. Bakken wrote:

Right now, dirname(__FILE__) seems to be the only solution that works. Does it solve all the problems of people trapped in PHP environment where they can't change php.ini?

I'm actually a bit afraid about the performance impact it might have to have dirname(__FILE__) calls all around the place. The probably best solution would be to have a new built-in constant (like __BASEDIR__), but this would force every PEAR user to update to the version of PHP that has introduced this feature ... --

   - Martin                           Martin Jansen
                           http://martinjansen.com/