|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #13936 Magical Constant __FILE__ contains wrong information on included files
Submitted: 2001-11-05 11:34 UTC Modified: 2002-09-28 15:19 UTC
Avg. Score:4.4 ± 0.7
Reproduced:5 of 5 (100.0%)
Same Version:1 (20.0%)
Same OS:3 (60.0%)
From: jpm at phpbrasil dot com Assigned:
Status: Closed Package: Scripting Engine problem
PHP Version: 4.3.0-dev OS: Solaris
Private report: No CVE-ID: None
 [2001-11-05 11:34 UTC] jpm at phpbrasil dot com
[jpm@mercury: Mon Nov  5 11:27:56]
[~]$ uname -a
SunOS mercury 5.8 Generic_108529-10 i86pc i386 i86pc

This is a very strange bug, as I have a similar piece of code running on the same server and it gives me the expected information (i.e. the full server related path for the script being run).

However, this simple set of scripts gives me the wrong information:

contents of test.php:
echo "original file is: " . __FILE__ . "<br>";

contents of test2.php:
echo "included file is: " . __FILE__ . "<br>";

$boo = "another try:  " . __FILE__;
echo $boo;

As described above, a similar piece of code works perfectly on the same server but using a different virtual host. This similar code is actually a bunch of classes that use a specialized Error handler class to report any problems, and the error is mailed to me. On these emails, I get the correct __FILE__ output and everything works as expected.

Any pointers would be very appreciated.

Joao Prado Maia


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2001-11-05 16:10 UTC]
You say that it doesn't work correctly, but what did you expect then, and what did PHP return?

I expect: (see the manual)

orig file: test.php
included file: test2.php
anothyer try: test2.php

And indeed:

[jjawolff@abeel]/tmp/php/php-4.0.6> uname -a
SunOS 5.6 Generic_105181-26 sun4u sparc SUNW,Ultra-5_10
[jjawolff@abeel]/tmp/php/php-4.0.6> ./php ../test.php
X-Powered-By: PHP/4.0.6
Content-type: text/html

original file is: ../test.php<br>included file is: /tmp/php/test2.php<br>another try:  /tmp/php/test2.php[jjawolff@abeel]/tmp/php/php-4.0.6>

So this probably not a bug, but a misunderstanding of __FILE__

(note: __FILE__ being '../test.php' is not what i'd expect, I expected an absolute path name)

 [2001-11-05 16:58 UTC]
Well, I expect PHP to give me the full path of the script (/usr/home/jpm/boohoo/test.php for instance) and not just 'test.php'.

What would be the purpose of __FILE__ if the full path was not returned ? We already have $PHP_SELF / $SCRIPT_NAME for the real name of the script.

Don't you think it is a bit strange that your own test gave you '../test.php' on the original script and then the full path for the included one ?

To go down to the real problem - I need a portable way to find the real location of the script on the server, being the server Apache, IIS, PWS or whatever you want to use. Using __FILE__ until now was the only way to get what I want, and now this problems is cropping up on me.

One more time, if __FILE__ is meant to be the way it is now (as you said, we probably have a misconception of what __FILE__ should return), then I need some other way to get the full path for a script in a portable way.

I'm putting this bug as open again so someone with a real answer can update this (no more 'probably' please ;)

 [2001-11-05 17:05 UTC]
Another good argument in favor of __FILE__ returning the full path is the actual purpose of this variable. People usually use __FILE__ and __LINE__ to develop routines to report problems or even events on their applications.

As the manual says, one could write something like this:

function report_error($file, $line, $message)
    echo "An error occured in $file on line $line: $message.";

report_error(__FILE__, __LINE__, "Something went wrong!");

To get a report of eventual errors on some library file. Can you tell me how would I know _which_ library file or script the error occurred without __FILE__ returning me the full path of the offending script ?

We could have several 'index.php' files running this 'report_error' function, and if __FILE__ returns only 'index.php', then we wouldn't know exactly which file it is.

Anyway, I think it is pretty clear __FILE__ should return the full path.

 [2001-11-05 17:24 UTC]
Yeah, ok, but that was far from apparent in your original report. So you mean that the bug is that not the full path is given?

I agree, that's a bug. __FILE__ should give the full path of the script in which the __FILE__ is.

I reproduce it with 4.0.6, but it apparently is fixed in 4.2.0, since with the exact same env and script etc I get the correct result now.

So closing.

 [2002-02-27 12:40 UTC] jas at cs dot yorku dot ca
I was having problems with this same thing on Solaris under PHP 4.1.1, so I tried the 4.2 version, and it seems to me that the problem is still there.

I create a file called "test.php" containing:
echo "file " . __FILE__;

When I:
php test.php

I get:
file test.php

I expect to get:
file /cs/home/jas/test.php

Shouldn't __FILE__ always return a full path to a file?

 [2002-02-27 13:42 UTC] jpm at phpbrasil dot com
Re-opening since this bug appear to be still going on. I didn't really test the fixes on 4.1.1 since I'm using a similar routine to report errors, but it would be nice to catch some attention.

 [2002-05-12 14:19 UTC] kumar at chicagomodular dot com
this bug is also happening with OS: Open BSD 3.0, PHP 4.2.0

the following was generated on maintenenance-priority.php 
(the other __FILE__ prints were generated from the included 


__FILE__: /config.php

__FILE__: / 

for the phpAdsNew application this is a serious bug since 
__FILE__ is used to define an include-path constant
 [2002-09-28 15:19 UTC]
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at
In case this was a documentation problem, the fix will show up soon at

In case this was a website problem, the change will show
up on the site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.

 [2004-04-01 03:54 UTC] roy at pine dot nl
We are running Solaris 7 with PHP 4.3.5 and the problem still exists.
I have tested the same setup on a FreeBSD machine with PHP 4.3.4 where it works like intended.
 [2004-07-06 11:08 UTC] lmalgras at tennaxia dot com
We have the same problem with PHP 4.3.3 on Windows 2000 SP1.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Sun Mar 26 07:05:48 2023 UTC