ID: 13936
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Variables related
Operating System: Solaris
PHP Version: 4.0.6
New Comment:
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
files):
__FILE__:
/home2/kumar/www/chicagomodular.com/phpAdsNew/
admin/maintenance-priority.php
__FILE__: /config.php
__FILE__: /lib-maintenance.inc.php
for the phpAdsNew application this is a serious bug since
__FILE__ is used to define an include-path constant
Previous Comments:
------------------------------------------------------------------------
[2002-02-27 13:42:37] [EMAIL PROTECTED]
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.
--Joao
------------------------------------------------------------------------
[2002-02-27 12:40:44] [EMAIL PROTECTED]
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:
<?php
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?
Jason.
------------------------------------------------------------------------
[2001-11-05 17:24:49] [EMAIL PROTECTED]
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.
--Jeroen
------------------------------------------------------------------------
[2001-11-05 17:05:30] [EMAIL PROTECTED]
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:
<?php
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.
--Joao
------------------------------------------------------------------------
[2001-11-05 16:58:46] [EMAIL PROTECTED]
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
------------------------------------------------------------------------
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
http://bugs.php.net/13936
--
Edit this bug report at http://bugs.php.net/?id=13936&edit=1
