ID: 24251 Updated by: [EMAIL PROTECTED] Reported By: qurve at qurve dot com -Status: Analyzed +Status: Closed Bug Type: Documentation problem Operating System: FreeBSD 4.7 PHP Version: 4.3.2 New Comment:
Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php I think this is already documented: http://www.php.net/include: "Files for including are first looked in include_path relative to the current working directory and then in include_path relative to the directory of current script. E.g. if your include_path is ., current working directory is /www/, you included include/a.php and there is include "b.php" in that file, b.php is first looked in /www/ and then in /www/include/." Previous Comments: ------------------------------------------------------------------------ [2004-06-29 18:49:29] noway at nowaysoft dot com Same problem here.. PHP 4.3.7 under Redhat 7.3 (compiled into apache). ------------------------------------------------------------------------ [2003-09-02 08:48:13] mathieu dot messe at urssaf dot fr I've got the same problem (The relative inclusions always take the requested page for directory reference.) on WinNT/php4.3.2 newly installed, but strangely I hadn't with WinNT/php4.3.0 A workaround found at http://fr.php.net/manual/fr/function.include.php is to use require(dirname(__FILE__) . "\..\second.php"); ------------------------------------------------------------------------ [2003-07-31 12:27:56] marv at cyberia dot net dot lb I posted this comment before but it seems to have evaporated. Is there a bug in the bug database? The problem lies with function php_fopen_with_path in php-src/main/fopen_wrappers.c The code is inconsistent with the what the documentation suggests (which is c-like behaviour). And since I think the documented behaviour is more intiuative, the code appears in-correct. Currently, the code is as follows: If the filename starts with a '.' (such as "../c/c.php" above), the function looks for the file relative to the 'main' script. Else if the filename is an absolute path, the function opens it directly. Otherwise, the function looks for the file relative to the directories listed in the 'include_path' configuration directive. If that fails, it then checks relative to the directory of the currently executing script. This has the consequences stated in the initial bug report. It also means that relative includes are always enabled. Adding a '.' path to the paths in include_path does not enable relative includes. It causes PHP to check relative to the 'main' script before checking relative to the currently executing script. I think it would be better if the function: Opens the file directly if it is an absolute path. Otherwise, scan the 'include_path' directive and replace a '.' path with the path of the currently executing script. Look for the file relative to the directories listed in the modified 'include_path'. ------------------------------------------------------------------------ [2003-06-23 22:21:04] [EMAIL PROTECTED] It's working just like it is supposed to be working. The working directory (cwd) is the one for the 'main' script, a.php in your case. NOT the directory where the 'sub' scripts are located. ------------------------------------------------------------------------ [2003-06-21 12:35:12] qurve at qurve dot com I should also note that this behavior isn't even consistent: +---+----------------+------------+----------------+-------------------+----------+ | # | file | includes | should include | actually includes | correct? | +---+----------------+------------+----------------+-------------------+----------+ | 1 | /root/a.php | b/b.php | /root/b/b.php | /root/b/b.php | yes | | 2 | /root/b/b.php | b2.php | /root/b/b2.php | /root/b/b2.php | yes | | 3 | /root/b/b2.php | ../c/c.php | /root/c/c.php | /c/c.php | no | +---+----------------+------------+----------------+-------------------+----------+ Behavior 1 works as it should Behavior 2 works as it should Behavior 3 works not as expected Behavior 2 and 3 are inconsistent with each other. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/24251 -- Edit this bug report at http://bugs.php.net/?id=24251&edit=1
