Vscode-php-debug: XDebugError: command is not available

[oojacoboo]

PHP version: 7.2.8
XDebug version: 2.6.1
Adapter version: 1.12.6

launch.json:

{
  "name": "Listen for XDebug",
  "type": "php",
  "request": "launch",
  "port": 9001,
  "pathMappings": {
    "/srv/www": "${workspaceRoot}/api/app"
  },
  "ignore": ["**/vendor/**/*.php"],
  "log": true
}

XDebug php.ini config:

; Disable Error and Exception modifications
xdebug.show_error_trace=0
xdebug.show_exception_trace=0

; General
xdebug.idekey="api-php"

; Profiling
xdebug.profiler_enable=0

; Remote
xdebug.remote_enable=1
xdebug.remote_autostart=1
xdebug.remote_handler="dbgp"
xdebug.remote_port=9001
; xdebug.remote_connect_back=1
xdebug.remote_host="docker.for.mac.localhost"
xdebug.remote_log="/var/log/php/xdebug.log"

Error from adapter log:

XDebugError: command is not available
at new Response (/Users/jacob/.vscode/extensions/felixfbecker.php-debug-1.12.6/out/xdebugConnection.js:56:19)
at Connection. (/Users/jacob/.vscode/extensions/felixfbecker.php-debug-1.12.6/out/xdebugConnection.js:611:20)
at Generator.next ()
at fulfilled (/Users/jacob/.vscode/extensions/felixfbecker.php-debug-1.12.6/out/xdebugConnection.js:4:58)
at code: 5, name: 'XDebugError'

[oojacoboo]

So, I was able to resolve this issue actually. I was able to get an error by enabling the "stopOnEntry": true, setting which tipped me off that the pathMappings value wasn't correct.

It's worth nothing that the variable, ${workspaceRoot}, is confusing if you have multiple "projects" within your "workspace". If so, the project directories aren't considered part of the path for the mappings.

Regardless of this, I still think the error should be addressed. It's seems unlikely that a command is not available error is okay under any condition.

[felixfbecker]

Please post the XDebug logs as stated in the issue template.

[oojacoboo]

Feel free to close if the stack and command not being available isn't sufficient to patch. I don't have a copy of the full logs anymore. It wasn't originally posted because it was incredibly long and I wasn't even sure where it started and ended from previous requests.

[animalillo]

Hello there, I seem to be having a very similar issue.
The debug console is overloaded with messages like this while the debugger seem to work perfectly fine:
{ XDebugError: command is not available at new Response (/home/user/.vscode-server/extensions/felixfbecker.php-debug-1.13.0/out/xdebugConnection.js:56:19) at Connection.<anonymous> (/home/user/.vscode-server/extensions/felixfbecker.php-debug-1.13.0/out/xdebugConnection.js:611:20) at Generator.next (<anonymous>) at fulfilled (/home/user/.vscode-server/extensions/felixfbecker.php-debug-1.13.0/out/xdebugConnection.js:4:58) at process._tickCallback (internal/process/next_tick.js:68:7) code: 5, name: 'XDebugError' }

This practically renders the debug console useless, i think that this kind of messages and errors should be on the output tab instead of on the console one.

Setting path mappings for all the projects that are interconnected on my dev machine using the ssh approach makes little to no sense if as by the previous comments this is related.

Should i provide any further logs or insight, please tell me and i will try my best to provide them

[japita-se]

Same here

XDebugError: command is not available
at new Response (/home/giuseppe/.vscode/extensions/felixfbecker.php-debug-1.13.0/out/xdebugConnection.js:56:19)
at new BreakpointSetResponse (/home/giuseppe/.vscode/extensions/felixfbecker.php-debug-1.13.0/out/xdebugConnection.js:207:9)
at Connection. (/home/giuseppe/.vscode/extensions/felixfbecker.php-debug-1.13.0/out/xdebugConnection.js:599:20)
at Generator.next ()
at fulfilled (/home/giuseppe/.vscode/extensions/felixfbecker.php-debug-1.13.0/out/xdebugConnection.js:4:58) {
code: 5,
name: 'XDebugError'
}
Error applying xdebugSettings: command is not available

[kiocosta]

Anyone solved it? I have the same issue

[anonymous-explorer]

I saw this error after I disabled PHP Intellisense plugin in VS Code. I had both PHP Intellisense and PHP Intellephense plugins enabled, so I decided to disable Intellisense. After I re-enabled Intellisense the error is gone.

[lcharette]

It's worth nothing that the variable, ${workspaceRoot}, is confusing if you have multiple "projects" within your "workspace". If so, the project directories aren't considered part of the path for the mappings.

This pointed me in the right direction. I have Foo and Bar "folders" within my workspace, which generate this error. This fixed the issue :

"pathMappings": {
    "/home/vagrant/Foo": "${workspaceRoot:Foo}",
},

A note should probably be added to the README doc.

[anothersailor]

Hmmm. Having the same problem here, in Local debugging, so I understand "PathMapping' is not needed. Sort of happened when I installed Valet to run my development, but may be unrelated.
Running PHP 7.2, xdebug-2.9.4, and VS Code with PHP debug extension v1.13.0 by @felixfbecker .
Same error, and the breakpoints have become totally unreliable.

Did anyone have success?
E.

[zer0pants]

I am not sure why this resolved the issue:

• I disabled PHP Intelephense,
• I disabled XDebug
• Restarted VSCode
• Enabled XDebug
• Enabled PHP Intelephense

Issue was resolved. Thanks @anonymous-explorer for the tip.

In my case I had only the simplest configuration:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9000
        }
    ]
}

[anothersailor]

Thanks! I will try!
E.

On 2 Apr 2020, at 05:57, Mike Roberts [e-mail] wrote:

I am not sure why this resolved the issue:

I disabled PHP Intelephense,
I disabled XDebug
Restarted VSCode
Enabled XDebug
Enabled PHP Intelephense
Issue was resolved. Thanks @anonymous-explorer https://github.com/anonymous-explorer for the tip.

In my case I had only the simplest configuration:

{
"version": "0.2.0",
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9000
},
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 9000
}
]
}
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/felixfbecker/vscode-php-debug/issues/321#issuecomment-607607189, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHYRAT2D3SW5H77UFF3BNDDRKQELRANCNFSM4GGJHXDQ.

[Schiocco]

Same problem and still not solution: XDebugError: command is not available

[anothersailor]

Yes, I found after trying that @zer0pants' solution did not work for me! So still open on my side as well.

[Schiocco]

The PHP debugger is completely not usable. It make my pages load
indefinitely until I stop the debug.

I found what does not create the error:

1. It is not the browser. The error persists also on different browsers.
2. It is not xDebug. The error disappears and everything works well with VS 2017 (same xDebug and XAMPP installation)
3. It is not the VS Code extensions. I disabled all the extensions and the error persists.

[japita-se]

Same problem here. But I have to say that it happens randomly. It seems that if you have an incognito browser opened the problem arises.

[JustinJKelly]

Same issue here. Works sometimes, and other times does not..

[ghost]

I found a solution for my particular case.
If you're using Docker, this may help you.

The message still shows BUT the Debug works perfectly for me.

What I have to do every time I turn off my PC is checking if the remote_host of XDebug in my common.env matches the gateway of the container of my application.

Here's how I do this:
1 -I install the Docker extension for VSCode.
2 - Once I finish installing Docker, its icon should appear on the toolbar along with Search, Debug, Extensions, etc. I click on it.
3 - In the "Containers" tab, I right click on the Container where my PHP is running and select "Inspect".
4 - I scroll all the way down and copy the Gateway address.
5 - In my case, I have a config for XDebug in my common.env. I paste the Gateway address in the remote_host (without any quotation marks):

XDEBUG_CONFIG='zend_extension="/usr/lib/php7/modules/xdebug.so" remote_host=PASTE_GATEWAY_HERE xdebug.remote_enable=1 xdebug.remote_autostart=1 xdebug.remote_handler=dbgp xdebug.remote_mode=req xdebug.remote_connect_back=0 xdebug.var_display_max_depth=-1 xdebug.var_display_max_children=-1 xdebug.var_display_max_data=-1 xdebug.remote_port=9001 xdebug.overload_var_dump=0'

5º Save the edited common.env and make sure the application is reading its new values. In my case, I restart the container: docker-compose up -d

I don't know why it changes every time and how I can make it watch the change, but to me this is sufficiently good for now.

If it works for you some times and other times it doesn't, I'd suspect it has something to do with addresses matching by luck sometimes and not matching other times. Make sure its remote_host is correct.

[lgoebkes]

Maybe this will help to get the configuration in docker environments more dynamic without manual steps.
For me using remote_host=host.docker.internal
fixed my issues with the chaning IPs.

[mubashirwaqar]

Applying new vscode update and restarting worked for me.

[therobyouknow]

Same issue here. Works sometimes, and other times does not..

It's a sorry situation if one has to debug the debugging environment itself.

I am not sure why this resolved the issue:

• I disabled PHP Intelephense,
• I disabled XDebug
• Restarted VSCode
• Enabled XDebug
• Enabled PHP Intelephense

Issue was resolved. Thanks @anonymous-explorer for the tip.

In my case I had only the simplest configuration:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9000
        }
    ]
}

turn it off turn it back on - classic blunt obtuse IT solution. Pleased you found it to work for you but it's not the root cause solution.

[therobyouknow]

Got it working using
"pathMappings": { "/var/www/html/web": "${workspaceRoot}" } in my launch.json

fingers crossed it continues to work!

After all, we are working with digital computers: either it does work (1) or it doesn't work (0) - right folks?!
And they don't have "off-days" either - switch 'em on and off we go, right?! yeah?

@oojacoboo's comment above about stopOnEntry: true was helpful as like them, for me it also helped me understand what was going wrong

https://github.com/felixfbecker/vscode-php-debug/issues/321#issuecomment-441518110

(the original error - "command not available" / "command not found" is f*cking useless - I mean WHAT command?!)

With stopOnEntry in my launch.json, I was able to see that xdebug/vscode could not open a file

My launch.json looks like this:

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for XDebug",
      "type": "php",
      "request": "launch",
      "port": 9000,
      "stopOnEntry": true,
      "pathMappings": { "/var/www/html/web": "${workspaceRoot}" }
    },
    {
      "name": "Launch currently open script",
      "type": "php",
      "request": "launch",
      "program": "${file}",
      "cwd": "${fileDirname}",
      "port": 9000,
      "stopOnEntry": true
    }
  ]
}

Also important to note relative locations of files - I feel this is crucial:

I have a top-level folder, gmb-develop within which everything underneath it is under git control. (The git bit isn't really relevant here but just for context)

Then I have a web folder, which is my docroot for my web application - Drupal 7 (php).

And my launch.json (shown above) is in the web folder in a folder called .vscode
So the path of my launch.json is: gmb-develop/web/.vscode/launch.json

So the location of my launch.json is interdependent with "pathMappings": { "/var/www/html/web": "${workspaceRoot}" } setting within it.

According to https://code.visualstudio.com/docs/editor/variables-reference though, ${workspaceRoot} is deprecated and ${workspaceFolder} takes its place. So I will try that ${workspaceFolder} next and update

Also - this is good to know: https://code.visualstudio.com/docs/editor/variables-reference#_how-can-i-know-a-variables-actual-value

• to check the actual value of variables.

Here's my screenshot of my setup working whereby the breakpoint has been hit:

And here's that more useful error that helped me (based on @oojacoboo's advice about"stopOnEntry": true, in launch.json :

Here's another screenshot showing my top level folder / "workspace" as being web - important to know in terms of the relative location of .vscode/launch.json Note that this .vscode/launch.json is a subfolder off of web top level folder.

and here's another screenshot showing the launch.json

Hope this help folks get xdebug running properly. Let's smack these problems down and stamp them out; who wants to debug their debugging setup, when they actually want to get the hell on with developing. And who wants to use sh*tty print_r, vardump and all that f*cking tin-pot cr*p either!!! Life really is too short... and it's sunny outside, I'd rather spend time out there than in here having my life stole away debugging my own debugging setup.

My setup is ddev for local development on Ubuntu 20.04

[EbubeUd]

My solution was to create a workspace for my project :)