Bug #13936 Updated: Magical Constant __FILE__ contains wrong information on included files

From: Date: Mon, 05 Nov 2001 21:58:47 +0000
Subject: Bug #13936 Updated: Magical Constant __FILE__ contains wrong information on included files
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-69662@lists.php.net to get a copy of this message
ID: 13936
Updated by: jpm
Reported By: jpm@phpbrasil.com
Old Status: Bogus
Status: Open
Bug Type: Variables related
Operating System: Solaris
PHP Version: 4.0.6
New Comment:

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 ;)

--Joao

Previous Comments:
------------------------------------------------------------------------

[2001-11-05 16:10:20] jeroen@php.net

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 abeel.students.cs.uu.nl 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 11:34:13] jpm@phpbrasil.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:
<?php
echo "original file is: " . __FILE__ . "<br>";
include("test2.php");
?>

contents of test2.php:
<?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

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



Edit this bug report at http://bugs.php.net/?id=13936&edit=1



Thread (8 messages)

« previous php.dev (#69662) next »