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

On Mon, 5 Nov 2001, Joao Prado Maia wrote: > > Good to hear that this bug was somehow fixed for 4.2.0. However, how can I > write a portable way to get the full path of a script ? I don't think is > acceptable for me to say to my users 'you shouldn't use 4.0.6, go use > 4.0.5 or PHP CVS'. It was broken in 4.0.3pl1 and 4.0.4pl1 too, so I guess it never worked correctly until 4.1.0 of 4.2.0 (didn't test 4.1.0) Jeroen > I would be very interested in hearing alternative ways to get the same > data. > --Joao > > > On 5 Nov 2001 jeroen@php.net wrote: > > > ID: 13936 > > Updated by: jeroen > > Reported By: jpm@phpbrasil.com > > Old Status: Open > > Status: Closed > > Bug Type: Variables related > > Operating System: Solaris > > PHP Version: 4.0.6 > > New Comment: > > > > 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 > > > > Previous Comments: > > ------------------------------------------------------------------------ > > > > [2001-11-05 17:05:30] jpm@php.net > > > > 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] jpm@php.net > > > > 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 > > > > ------------------------------------------------------------------------ > > > > [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 > > > > > > -- > > PHP Development Mailing List <http://www.php.net/> > > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > > For additional commands, e-mail: php-dev-help@lists.php.net > > To contact the list administrators, e-mail: php-list-admin@lists.php.net > > > > > -- > João Prado Maia <jpm@phpbrasil.com> > http://phpbrasil.com - php com um jeitinho brasileiro > -- > Precisando de consultoria em desenvolvimento para a Internet ? > Impleo.net - http://impleo.net/?lang=br > > Jeroen van Wolffelaar Jeroen@A-Eskwadraat.nl http://www.A-Eskwadraat.nl/~jeroen