Req #42516 [Com]: __FILE__ resolves symlinks
| From: | gerardreches at gmail dot com | 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