21

Does anybody know how to debug CLI PHP scripts from the CLI?!? I don't want to debug a PHP web page - I don't have a PHP web page. I don't want to debug a remote script either - I'm running/debugging right here on this system. I don't want to (at this time) try to get some IDE (Eclipse, PhpStorm or whatever) to debug a CLI PHP rather I just want to debug some PHP CLI script at the Linux command line itself. In Perl this would be simply perl -d <script.pl> <options>. Debugging a script, to me, is not figuring out compile errors or other simple things. To me it's setting break points, running code, examine the contents of variables and being able to arbitrarily execute or eval ('<php code>') at the debugger.

Sure later I'd like to configure this into my IDE of choice (at this time this is Eclipse) but I have not managed to get that working. Debugging from the CLI a PHP CLI script would be a good start for me.

Thanks.

I don't know why I'm limited to a character count when posting a comment. Perhaps I can add more text here.

Here's what I have tried in order to use xdebug and/or Zend debugger with Eclipse:

  • Base Eclipse version Mars.1 Release 4.5.
  • Eclipse PDT UI Plugin version 3.7.0.2015112
  • Tried installing xdebug using pecl install xdebug. Says I need to add "zend_extension=xdebug.so" to php.ini. Really? Which php.ini? I have several:

Andromeda:sudo find / -xdev -name php.ini /etc/php5/cli/php.ini /etc/php5/apache2/php.in /opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php53/php.ini /opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php5/php.ini /opt/eclipse/plugins/com.zend.php.debug.debugger.php56.linux.x86_64_13.0.1.v20151112-2045/resources/php56/php.ini Andromeda:

  • I put the zend_extension thing in both /etc/php5/cli/php.ini and /etc/php5/apache2/php.ini. Made a phpinfo.php page and I see Xdebug in there (yea!). Configure a Debug Configuration in Eclipse to use xdebug and try to debug:

Launching renameUser has encountered a problem. An internal error occurred during "Launching renameUser" java.lang.NullPointerException.

Oh goodie...

  • I had also installed the Zend Debugger and added the following to those same two php.ini files:

zend_extension=/usr/lib/php5/20121212/ZendDebugger.so zend_debugger.allow_hosts=127.0.0.1/32, 192.168.0.0/16 zend_debugger.expose_remotely=always

  • Changed debug configuration to use Zend Debugger and attempted to debug. Received:

Error launching 'renameUser' The debug session could not be started. Please make sure that the debugger is properly configured as a php.ini directive.

  • Restarted Eclipse and now the debugger attempts to run but simply terminates with a 255 exit value attempting to run /opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php5/php-cgi. Why it's runnign php-cgi is beyond me. I said this was a CLI not a CGI. In any event I get the following when trying to run this from the command line:

Andromeda:/opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php5/php-cgi /opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php5/php-cgi: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory

  • Found a libiconv.so.2 in /opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/lib and set LD_LIBRARY_PATH to include that but this just fails to launch the debugger at all stating to make sure that the debugger is properly configured as a php.ini directive... UGH!

Other odd stuff:

  • When Eclipse starts up it fails to open my RSE based project thus displaying edit buffers from the last run as empty
  • Eclipse will no longer exit! Select File: Exit. Nothing happens. Click on the X in the title bar - nothing happens. Now I have to kill it to close it!

5 Answers 5

20

When debugging on the command line you need to tell PHP you want to debug also

http://xdebug.org/docs/remote

says

export XDEBUG_CONFIG="idekey=session_name"
php myscript.php

assuming xdebug is enabled (it doesnt matter which .ini file its in, but there is a standard place per OS for this, usually in a conf.d folder called xdebug.ini which is auto included)

This allows you to debug a cmdline script.

Personally I use Vim with Vdebug extention (xdebug for vim) to debug and nothing other than a command line is needed

Sign up to request clarification or add additional context in comments.

2 Comments

I tried that but it didn't work. This comment syntax doesn't work. Sorry, I tried. Andromeda:export XDEBUG_CONFIG="idekey=session_name" Andromeda:php renameUser.php Creating user key Object Done Creating p4 connection PHP Fatal error: Cannot instantiate interface P4\Connection\ConnectionInterface in /opt/perforce/swarm/renameUser.php on line 24 PHP Stack trace: PHP 1. {main}() /opt/perforce/swarm/renameUser.php:0 Andromeda:
@AndrewDeFaria sounds like your PHP script is hitting a fatal error before it hits your breakpoint.
3

What worked for me was using dephpugger. I found the steps to get CLI debugging working here:

https://hackernoon.com/how-debug-php-applications-with-dephpugger-98cc234d917c

I had previously installed xdebug and tried out exussum's answer.

The steps I followed are included here for completeness.

Install dephpugger:

composer global require “tacnoman/dephpugger”:”dev-master”

Put dephpugger on the path:

export PATH=$PATH:$HOME/.composer/vendor/bin

make sure to include in the php file at the breakpoint:

xdebug_break();

open up 2 terminal instances. In one run:

dephpugger debug

In the other run

dephpugger cli /path/file.php

replacing /path/file.php with the path to your file. if you need command line arguments to the php script put the path and arguments in quotes. It still seems a little hacky. I think the real trick is to write in a language that has a better debugger built in.

1 Comment

it's hacky but it is the fastest solution at private scripts
2

exussums answer works for me.

In addition I have the following in /etc/php/7.0/cli/conf.d/20-xdebug.ini

zend_extension=xdebug.so

xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp

xdebug.remote_enable=true
#xdebug.remote_enable=false

And I had to do this: https://github.com/vim-vdebug/vdebug/issues/363

1 Comment

This is what worked for me. The XDebug page claims it will "just work" if the debugger and script are running on the same system, but this was a lie. Setting it up this way to remote loopback works.
0

Being able to set break points in a PHP script requires some kind of debugger extension being loaded, either XDebug or Zend Debugger.

And then you need some kind of interface to this debugger to make your wishes about break points known. I am unfamiliar with the Perl debugging, but I haven't heard about any PHP CLI based debugging - it is always taking place in an IDE that is able to handle the debugging protocol of one of the extensions.

Of course there is the good old var_dump();die('hi'); debugging, but this does not include continuing code execution after the script ended. ;)

7 Comments

In Perl you simply say perl -d script.pl. The debugger is baked in and just works. Why PHP needs help is beyond me! Why it needs a debugging "protocol" seems dumb or at least overblown for a situation where you are just writing a CLI script. In Perl the debugger "extension" is simply perl5db.pl. When -d is specified Perl simply loads the debugger and then calls it. Viola you're debugging! The interface in a CLI debug session is the command line! What else would it be?
OK, so I have Eclipse (4.4 IIRC and I'm on Ubuntu 14.10 myself and the script I'm trying to debug will need to run eventually on CentOS 5.6) and I tried to install both the Zend debugger and the XDebug thing. Neither worked. Eclipse either did nothing when asked to start debugging or displayed an error dialog saying the debugger was not configured correctly. Perhaps if you could give me exacting, step by step instructions I might be able to do that. I do recall it telling me to put dummy.php at my web server's root. Well I have no web server because I have no web app that I'm trying to dbg.
Methinks, regardless of PHP saying it's just fine for doing CLI work, that PHP is ill suited for CLI development, especially in the area of debugging. And var_dump and die are a terrible way to debug things! I'm trying to run PHP stuff from the vendor and want to step into and through their code to understand how to use it. I can't be putting var_dumps all through their code. (limiting the size of the comment - dumb)
Perhaps you should explain why you think you need debugging access to a PHP CLI script. What kind of problem do you experience? I know it sounds complicated to set up a working PHP debug environment, but that's what every PHP developer has done or should do. However, running a debugger isn't the only way to get more info about errors - there are error messages and log files. What are you trying to do?
As I said before, I'm trying to trace the execution of a PHP script that uses a number of classes from vendor provided PHP files. These are not errors as per se, but I'm trying to reverse engineer how to use the PHP objects that this vendor provides so I can call into them to perform a function. But really, do I need to justify why I want to use a debugger? In general, here or anywhere - how do you debug PHP scripts - specifically PHP CLI scripts?!? And how can I enter in text here without being limited to a small number of characters?!?
|
0

There is an "official" xdebug Command Line Debug Client: https://xdebug.org/download#dbgpClient

In my opinion, it could be made way better, but it does help:

  1. Install PHP xdebug (https://www.youtube.com/watch?v=MmyxWy8jl7U) with default port 9003
  2. Link dbgpClient to PATH
  3. run dbgpClient
  4. Add at least one xdebug_break(); in your PHP to mark a break-point
  5. Run your PHP CLI script in another shell
  6. Pass in commands into dbgpClient: (step_into, context_get, ...)
Command Description
breakpoint_set -t line -f file:///xdebug-test-2.php -n 5    Sets a breakpoint on line 5 of file:///xdebug-test-2.php
step_into   Steps to the next executable line in the code
run         Runs the script until the next breakpoint, or when the script ends
context_get Lists the variables and their values in the current scope
property_get -n $a  Retrieves the value of the property $a

https://xdebug.org/download#dbgpClient

https://xdebug.org/docs/dbgpClient

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.