Edit report at https://bugs.php.net/bug.php?id=42516&edit=1
ID: 42516 Comment by: daniele dot segato at gmail dot com Reported by: michael at zedeler dot dk Summary: __FILE__ resolves symlinks Status: Open 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: 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 Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2011-04-13 09:32:46] tyra3l at gmail dot com $_SERVER["SCRIPT_FILENAME"] can be used for getting the non-resolved path, and the documentation at http://php.net/manual/en/language.constants.predefined.php now contains info about __FILE__ is resolved to absolute path with resolved symlinks. so I think that this could be closed. Tyrael ------------------------------------------------------------------------ [2009-08-17 12:57:30] michael at zedeler dot dk Fixed subject. ------------------------------------------------------------------------ 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
