Re: include_path question

From: 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

« previous php.dev (#30831) next »