Re: include_path question
| From: | Andi Gutmans | Date: | Sun, 27 Aug 2000 18:35:39 +0000 |
| Subject: | Re: include_path question | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-30827@lists.php.net to get a copy of this message | ||
At 11:23 27/08/00 -0700, Rasmus Lerdorf wrote:
Any idea why it was decided "a zillion years ago" that if you define an include_path scripts from the current directory won't be opened unless the include_path includes .? For example if you have a script: /path/to/script.php which is your main script, i.e. PATH_TRANSLATED then include"foo.php" from within script.php won't open /path/to/foo.php unless include_path has "." or include_path is not defined at all. Is this how ppl remember it? Why is it like this? I suppose the logic was to make it consistent with the notion of a search path. If you provide a search path you expect PHP to honour this path and not open files from anywhere outside of the given search path. We could make an exception for "." but are you actually seeing people getting confused over this? It has bee this way for a long time.Yes I think it really is sort of the UNIX search path vs. the DOS search path thing. There actually don't seem to be many people who get confused about this which is kind of strange although I have seen some people here and there. I got confused when trying to debug some of the fopen() stuff. I don't necessarily think it's wrong I just wasn't quite sure about it and had three options in mind: a) I was wondering if there was a reason such as a security reason. b) I thought there might be a bug and it's supposed to open the local file even if include_path exists. c) Forgot what c) was :) So I guess it's OK. Let's just wait and see if we can fix the current include_path problem. Hopefully the patch I submitted will solve it but who knows? Andi --- Andi Gutmans <andi@zend.com> http://www.zend.com/