Edit report at https://bugs.php.net/bug.php?id=46260&edit=1

 ID:                 46260
 Updated by:         paj...@php.net
 Reported by:        bugs dot php dot net at callum-macdonald dot com
 Summary:            __FILE__ should not resolve symlink paths
-Status:             Open
+Status:             Duplicate
 Type:               Feature/Change Request
-Package:            Feature/Change Request
+Package:            *General Issues
 Operating System:   Linux
 PHP Version:        5.2.6
-Block user comment: No
+Block user comment: Yes
 Private report:     N

 New Comment:

@alex at wordnik dot com

It is required as part of the require/include_once function. Sources file paths 
are always resolved. It is not a bug but a design choice, which allows many 
optimization.

That being said, anyone using symbolic links in prod across different sites 
should reconsider this choice as well.

Let close this bug and mark as duplicated.


Previous Comments:
------------------------------------------------------------------------
[2012-04-30 22:23:48] alex at wordnik dot com

After 4 years of bug report, this issue still remains.  Unbelievable.  It's 
such 
a small change to make the behaviors more consistent (and correct), and helps 
simplify developer's life.

No flamebait here, but no wonder PHP is like a dead language, with most people 
move on to other languages, Python, Ruby, to name a few, while those who are 
stuck with PHP for Wordpress and other sites, suffer.

------------------------------------------------------------------------
[2012-04-23 09:16:36] sdbondi at gmail dot com

So nothing is being done about this issue?

It seems to have been an issue for at least 6 years without
a adequate solution. 

The behaviour of the __FILE__ constant seems in violation 
of convention and what developers would expect from it.
This bug (yes, bug) prevents us from keeping code (like 
wordpress and a theme) in their own repositories in e.g.
Git (cannot checkout sub-folders - git submodules would 
only work if you didn't want to keep theme build, 
documentation etc. files versioned in the repo). 

I really don't get why this behaviour is not at least configurable.

What is the use case of resolving symlinks? 
I suspect no one would be able to find a use that couldn't
be done in a better way.

------------------------------------------------------------------------
[2011-12-28 13:40:41] contato at mesotec dot com dot br

+1 too. I really need this feature.

In windows 7 realpath for a file that is accessed through a mklink folder does 
return the link path not the absolute one.

------------------------------------------------------------------------
[2011-12-26 15:51:42] bugs dot php dot net at callum-macdonald dot com

I tested monsen.dag's suggestion and it produced a completely different result 
than expected. Also, defining a constant will only apply once, not to the 
*currently executing file*, which is the great advantage of __FILE__. This 
suggestion does not provide a solution of any kind as far as I can tell.

------------------------------------------------------------------------
[2011-12-22 13:45:24] monsen dot dag at gmail dot com

If you're on an enviroment with bash available, you can use this snippet to get 
__FILE__ without resolving symlinks.

It's a small hack, but it should be pretty safe.

<?php
$output = array();
exec('pwd', &$output);
define('__LINK__', $output[0].substr(__FILE__, strpos(__FILE__, 
DIRECTORY_SEPARATOR)));
?>

------------------------------------------------------------------------


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=46260


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=46260&edit=1

Reply via email to