RE: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.

I think it's the 'right' thing to do, even though that too requires some thinking. If we move to always use the virtual cwd system in TSRM (any reason not to?) then there'll be pretty much no performance implications either. Zeev At 20:08 9/7/2001, Andi Gutmans wrote:

At 12:07 PM 7/9/2001 -0700, Brian Tanner wrote:

Just want to pipe up and say I'm worried about a potential performance hit here. I'm building an enterprise web app that includes over 30 files on every request. Will changing the directory for the include file, and changing it back after create a significant performance hit? (I would think so).

I think that it will effect performance and therefore I wouldn't want to go in the direction of chdir(). Andi

Just to point out -- things might get a little more confusing here... because if people get to pretend that the file they are including is being executed in the directory where it is stored, they may have problems adjusting to the idea of making links and images (in HTML) relative to the script that called their file, and they might have to end up re-implementing existing workarounds anyway. Just a thought. -Brian Tanner -----Original Message----- From: Zeev Suraski [mailto:zeev@zend.com] Sent: July 9, 2001 5:48 AM To: Andi Gutmans Cc: php-dev@lists.php.net Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. Yeah, this has been requested several times. I think that changing the cwd to the directory of an included file makes good sense. It is, indeed, downwards incompatible and may break existing applications. We have 4 options: 1. Do nothing 2. Make include() and friends change directory to the directory of the file they include. This makes the most sense, but may break existing apps. 3. #2, only make it optional 4. Add the directory of the included file to the include_path when the included file is being executed. It can get a bit nasty with nested includes, even though I think it should work. It's also a bit tricky to implement, as the engine doesn't know about include_path (at least right now). I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. Zeev At 18:14 8/7/2001, Andi Gutmans wrote:

Hey, I think one thing that bothers PHP developers is when they do: include "../foo.inc"; and in foo.inc they do: include "bar.inc"; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? Andi -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

-- Zeev Suraski <zeev@zend.com> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

-- Zeev Suraski <zeev@zend.com> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/