BTW: I am apparently not the only one:
http://stackoverflow.com/questions/21254661/xdebug-weird-dir-constant
http://stackoverflow.com/a/30290059/310011
https://laracasts.com/discuss/channels/laravel/new-to-laravel-taking-over-development/replies/109105

Additionally because every time I wrote it people assuming I am using "eval", so just to clarify I don't
For debugging I am using phpStorm 2016.2.2

Hi,

thanks for the report. In order to find and fix the bug, I really do need a reproducible case. As this seems to be a remote debugging issues, please refer to https://xdebug.org/support.php#remote as to what I would require.

cheers,
Derick

Sure thing, here is the script: https://gist.github.com/Radek-Suski/660a8b820c98763304fa8617fa7c77d1
Here is the log file: https://www.dropbox.com/s/kq5sst1maot4he4/xdebug-log.log?dl=0

What really weird, I just realised, that debugging this script gives following results:

__FILE__ = "xdebug://debug-eval"
__DIR__ = "xdebug:"
$file = "/www/Neo/libraries/Sobi/index.php"
$dir = "/www/Neo/libraries/Sobi"
$dirname = "/www/Neo/libraries/Sobi"

Which means that if I assign those constants to variables, those variables are having correct values.

Regards,
Radek

Hi,

I see what happens now. You have these in the "Watches" field. PhpStorm handles watches by running the DBGp "eval" command. In the log, that looks like:

<- eval -i 62 -- JEdMT0JBTFNbJ0lERV9FVkFMX0NBQ0hFJ11bJzlmNmZiNjcxLWU0ZWItNDIyNy04Mzc2LTNhNjNkZDNiMmNmMCddPV9fRElSX18=

As the eval command really just calls PHP's eval, you get the same result:

$ php -r "echo eval('echo FILE;');"
Command line code(1) : eval()'d code

Xdebug does replace the "Command line code(1) : eval()'d code" with "xdebug://debug-eval" though.

This is something I can not change.

@derick Thank for your answer. Yet I am not sure if you are entirely correct. Yes, I have it in watches. But even if, the logical execution is failing. I am asking:

if(file_exists( DIR.'/file.php'))

and it returns "false". It can't be just because I have it in my "watches" because at the first time I was debugging my case, it wasn't

No, it can't be because it's in watches. But that "file_exists" would only file for real reasons. If you can reproduce this, I would use "strace -o /tmp/strace.log php script.php" and see for which file it is doing a "stat".

I know for sure that this file exists. That's how I figured out this issue

Okay - I would definitely use the strace then. There must be something why PHP thinks it's not there, and strace is your only hope I think.

no problem. I will try to deliver it soon. Thank you very much

(Changing it to feedback until you do).

Ping?

I am closing this, as I can't reproduce this, and the requested feedback has not been given. Please feel free to reopen this if you can provide more information as requested.

This error is repeated for me! How can I fix it? xdebug 2.5.5-1

Xdebug 3.2.1, the problem persists (as far as I understand, in all other versions too). To reproduce it, it is enough (when working in phpstorm) during a debugging session to open the Evaluate Expression window (alt + F8) and enter one of these constants there. You can just use the debug console, you can use the clock, the behavior is the same everywhere.

@anton.m4354: I would still expect what you show. When PhpStorm evaluates __DIR__ or __FILE__, it uses eval under the hood. This evaluates the string, exactly what this would do:

echo eval(__DIR__);

Which on the PHP CMD also produces a similar result:

php -r "echo eval('return __FILE__;');"

Returning:

Command line code(1) : eval()'d code

Xdebug does wrap that in its own file name though, which is xdebug://debug-eval. There is nothing I can change here, and I am not sure whether PhpStorm can, but you can always ask them at youtrack.jetbrains.com/

@derick that is, if Phpstorm would directly echo __FILE__;, then the result would be correct?

@derick, well, I tried to display the FILE constant in cmd with and without eval, and the difference is that without eval there will be no right-hand side of the "eval()'d code". And in the case of a constant, DIR is not replaced there at all, and is output correctly.

And you said that xdebug wraps in its filename, that is, in xdebug:. But you are developing xdebug, it’s not entirely clear why then you can’t do anything with it

image.png (5,515 bytes)   

image.png (5,515 bytes)   

image-2.png (6,156 bytes)   

image-2.png (6,156 bytes)   

@derick I think I understand what's going on. I’m certainly not a C++ programmer, but after looking at your repository, as well as the php source repository, I saw a function like zend_eval_string(), and you pass xdebug://debug-eval as parameter 3 to it. And in the php source code, where php-cli is implemented, I accordingly saw how the 'Command line code' is transmitted there. This suggests that this is most likely a required parameter of the function, and the function itself makes the substitution.

But nevertheless, if you run debug_backtrace()[0] in the debug console, then in its output you can see the correct full path to the file, and from it you could get values equivalent to __FILE__ and __DIR__. This means that when executing the code in zend_eval_string(), it is not impossible to get the real path of the folder and file, they just apparently do not go into the magic constants for some other reason. But since this function is part of the Zend Php API, then perhaps it’s worth creating a corresponding ticket in the Php developer tracker and transferring this matter to them?

UPD: I noticed that debug_backtrace[0] does not always display the file where the stop occurred. In some cases, xdebug:/debug-eval is displayed there. But anyway, in this case the file with the breakpoint is already in the next element of the result array - in debug_backtrace[1]. That is, there is still information about him

image-3.png (205,657 bytes)   

image-3.png (205,657 bytes)   

The PHP interpreter replaces __FILE__ and __DIR__ with the directory name and file name of the file being parsed.

If Xdebug calls zend_eval_string (or you, in a PHP script run eval), then there is no file associated with the code that is being evaled.

The third argument to zend_eval_string is just so that PHP can show parse errors with a reasonable name. It is not possible to override __DIR__ and __FILE__ through this.

@derick Well, I’m not saying that you need to redefine constants through the third argument in zend_eval_string, I’m suggesting to open a ticket for the php developers in their tracker so that they change the behavior of this function