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

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'. 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