Re: include_path question
| From: | Sascha Schumann | Date: | Sun, 27 Aug 2000 19:04:48 +0000 |
| Subject: | Re: include_path question | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-30831@lists.php.net to get a copy of this message | ||
On Sun, 27 Aug 2000, Andi Gutmans wrote:
> At 20:38 27/08/00 +0200, Sascha Schumann wrote:
> >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.
>
> Yeah I was just wondering why it was done this way. Again, I didn't say it
> was wrong.
Well, I was just pointing out that there is an inconsisteny
which had not been mentioned in the debate (PHP 3 always uses
"." independent of the include_path setting).
> > What problem does it fix exactly? And why did you readd
> > php_realpath.c?
>
> I readded php_realpath.c? I didn't. The commit msg is broken.
Strange. I've never seen that before.
> It fixed the problem that when you try and open the main script which
> should be a full path name (PATH_TRANSLATED) it was opening the filename
> and not the whole path which meant that php_fopen_wrappers() needed "." to
> be in the include_path if include_path was being used. The filename should
> stay intact and you should just CHDIR to the right place.
What is the logic behind php_fopen_wrapper() caring about the
the filename currently handled by Zend?
> What SAPI module passes relative path? path_translated should always be
> full path and if it is not then it's a problem in the SAPI modules and not
> in main.c.
At least thttpd does, but there are numerous I don't know
about (like pi3web, Zeus, Roxen).
- Sascha