Re: include_path question
| From: | Sascha Schumann | Date: | Sun, 27 Aug 2000 18:38:39 +0000 |
| Subject: | Re: include_path question | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-30828@lists.php.net to get a copy of this message | ||
On Sun, 27 Aug 2000, Andi Gutmans wrote:
> 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.
Additionally, it is not consistent with PHP 3.
> 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?
What problem does it fix exactly? And why did you readd
php_realpath.c?
The change breaks SAPI modules which pass a relative path to
PHP (i.e. foo/bar/file.php). PHP will now chdir to foo/bar
and will try to open the file foo/bar/file.php in that
directory which will fail, of course.
- Sascha