Edit report at https://bugs.php.net/bug.php?id=42516&edit=1
ID: 42516 Updated by: paj...@php.net Reported by: michael at zedeler dot dk Summary: __FILE__ resolves symlinks -Status: Open +Status: Not a bug Type: Feature/Change Request Package: Scripting Engine problem Operating System: Linux PHP Version: 4.4.7 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php It is required by require_once and include_once, along other things (realpath cache). It always been like that. Previous Comments: ------------------------------------------------------------------------ [2013-01-23 17:36:39] ale dot comp_06 at xox dot ch On development server I often have symlinked directories to common libraries. It would be wonderful to have an option for the behavior of __FILE__ and allow it to return the non resolved path if the developer wishes so. Generally speaking, having some paths automatically "resolved" and some not, is very disturbing. As far I can tell, all paths should be unresolved and one should use "resolve_path()" to get the "real" path. A central switch should allow to get all the paths resolved if one wants so (or the other way: the default being the paths being resolved and the switch makes them unresolved). ------------------------------------------------------------------------ [2012-06-15 07:43:47] daniele dot segato at gmail dot com This bug was open since 2007 would you mind assigning it to someone for fixing or discuss why you are leaving it open? maybe someone out there can help you thank you ------------------------------------------------------------------------ [2012-04-06 17:28:55] bj...@php.net I don't know why this was assigned to me ------------------------------------------------------------------------ [2011-08-20 09:56:33] clicky at erebot dot net Also, the DOCUMENT_ROOT workaround only works in case you're dealing with a website. It's completely useless in case you're working from a terminal (eg. some unit tests run through PHPUnit). +1 on having this behaviour changed (maybe as a second magic constant as other proposed, so as not to break backward compatibility for __FILE__). ------------------------------------------------------------------------ [2011-07-20 05:23:46] mpok at xs4all dot nl @Tyra3l: the problem most people (including myself) are having is that $_SERVER["SCRIPT_FILENAME"] contains the path to the file that was called, not the path to the file that is actually processed. This means you can't use $_SERVER["SCRIPT_FILENAME"] as a replacement for __FILE__; in fact there is no way to get a non-resolved path to the current script. Example: Website calls [DOCUMENT_ROOT]/index.php Cronjob calls [DOCUMENT_ROOT]/lib/cron/maintenance.php Both files include [DOCUMENT_ROOT]/lib/config/startup.php Now the startup.php script has to set path variables/constants to use throughout the framework. If you use __FILE__ for this it will return the path to the settings.php script, regardless of whether it was included/called from the website (index.php) or the cronjob (maintenance.php). This allows you to reliably set paths relative to the location of settings.php. However if you symlink the /lib/ directory __FILE__ will resolve the symlinked path and thus break for setting the framework paths relative to the website. Using $_SERVER["SCRIPT_FILENAME"] in startup.php will result in different paths depending on which file was called. When called from the website it returns " [DOCUMENT_ROOT]/index.php", when called from the cronjob it returns " [DOCUMENT_ROOT]/lib/cron/maintenance.php". This means that if you want to make sure you get a reliable path to the lib inside the website you'd have to write a bunch of additional code with semi-intelligent matching in order to find a specific path, if at all possible. Another option is to set the base path seperately in each file that is an entry point for the framework so that those files define their existence relative to the lib dir. This does create more dependencies though. All in all it would be far better if there was an option in the php.ini to disable symlink resolving for __FILE__ (and subsequently __DIR__). If I want to resolve symlinks I'd use realpath() anyway. ------------------------------------------------------------------------ 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 https://bugs.php.net/bug.php?id=42516 -- Edit this bug report at https://bugs.php.net/bug.php?id=42516&edit=1