Req #42516 [Com]: __FILE__ resolves symlinks

From: Date: Fri, 05 Jan 2024 06:56:26 +0000
Subject: Req #42516 [Com]: __FILE__ resolves symlinks
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-246178@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=42516&edit=1 ID: 42516 Comment by: gerardreches at gmail dot com Reported by: michael at zedeler dot dk Summary: __FILE__ resolves symlinks 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: I am using WordPress and instead of copying my plugins files for each WordPress installation, I am using them through symlinks. Some of these plugins require the unresolved path for WordPress to be able to enqueue styles and scripts. These plugins may either be used as a plugin or a library as part of another plugin, which makes alternatives to retrieve the path unusable. 17 years, multiple requests, and nothing has been done yet about this. We are not even asking for the __FILE__ and __DIR__ behaviour to be changed, but to get a new pair of constants that return the unresolved path. Previous Comments: ------------------------------------------------------------------------ [2021-05-26 11:55:38] zjz at zjz dot name Here's a scenario where symlinks-unresolved path constants are helpful: Suppose there are two sub-projects d1 and d2, and I want to reuse some file of d1 in d2, then I apply soft link to it: /<path-of-d1>/f1.php /<path-of-d1>/f2.php /<path-of-d2>/f1.php --> /<path-of-d1>/f1.php (soft link) /<path-of-d2>/f2.php The content of /<path-of-d1>/f1.php contains the following the include directive: include __DIR__ . '/f2.php'; The included path is always resolved as /<path-of-d1>/f2.php, it would be unfortunate if in fact we want the /<path-of-d2>/f2.php to be included. I think introducing a new pair magical constants corresponding to __FILE__ and __DIR__ is desirable. Thank you. ------------------------------------------------------------------------ [2018-12-03 00:47:15] pmugane at gmail dot com Really concerned about how this whole process has been ignored. If __FILE__ is intended to resolve symlinks by design then provide a way to get the directory of the symlink - it's really not that hard. Seriously, it's been over a decade and this is still unresolved. ------------------------------------------------------------------------ [2013-01-24 15:21:52] michael at zedeler dot dk I agree that this isn't a bug. I filed it as a change/feature request. Please revert. ------------------------------------------------------------------------ [2013-01-23 19:01:16] pajoye@php.net 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. ------------------------------------------------------------------------ [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). ------------------------------------------------------------------------ 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

« previous php.bugs (#246178) next »