Winpdb - A Platform Independent Python Debugger Launch Time
Launch with an X Terminal
The simplest way to start a debugging session on GNU/Linux is to type winpdb in a terminal followed by the script name and it arguments. For example:
winpdb myScript.py arg1 arg2 arg3
Winpdb acts as a client and starts the debugged script in a new process that acts as a server. The new process is started either in a new X terminal or in a new screen virtual-terminal. Winpdb intentionally does not redirect IO from the debugged script process to the debugger client process.
You can also launch a debugging session from the debugger console with the launch command like this:
launch myScript.py arg1 arg2 arg3
Attach - Don’t start a New Terminal
Winpdb always uses a separate terminal for the debugged script (unless you are using the screen utility) but you can prevent Winpdb from trying to start the terminal by itself. To do this, start the debugged script server in one terminal and then have Winpdb attach to it from another terminal. To start the debugged script server use the -d command line flag. To allow the server to accept connections from remote machines add the -r flag. For example:
rpdb2 -d -r myScript.py arg1 arg2 arg3
If you have wxPython installed you can replace rpdb2 with winpdb in the above example, but as the server has no GUI it does not matter.
To attach to the debugged script server use the password, host and attach console commands in the debugger client (Winpdb). Type help in the console for more information. Alternatively you can use the GUI as described below.
GUI Guide
Set a Password
To set the connection password click File->Password. This option is available only when the debugger is in the detached state.
Attach to a Script
To attach to a script click File->Attach. This option is available only when the debugger is in the detached state. If the attach option is selected without a password having been set, the password dialog will pop up automatically, requesting for a password. To attach to a script on a remote machine, type the machine hostname or IP address in the Host edit box and click on the Refresh button. Only scripts that match the password will show up in the dialog. Also, note that connectivity issues such as firewall protection may prevent scripts from being detected.
This doc should be written to also explain the console interface, for users not running the gui stuff.
Even the console debugger (rpdb2) tries to start an xterm! Why does it do that?! I’m debugging on a remote machine over an ssh connection and can’t start an xterm.
rpdb2 includes internal help. Type help (or help at the console prompt.
rpdb2 uses two processes, a client (the debugger console) and a server (the debugged script). This is why it usually uses two terminals.
You can limit rpdb2 to use one with the screen utility. Type rpdb2 -h and see the help on the -s command line switch.
Oh good, I can run without crypto. But even the debuggee mode tries to open an X terminal. Why is that? I don’t have X on this box. It suggested running screen but that gives some error message about not being able to open /dev/pts/2. Shouldn’t debuggee mode just use a socket and nothing else? No console, no X client.
Prevent the debugger from trying to start a new terminal with the -d command line flag.
The -d command line flag makes the debugger start as a server (debugged script) and wait for clients to attach (debugger consoles).
If you do not use the -d flag the debugger starts a client (debugger console) and tries to launch a server (debugged script process) and attach.
If you want to allow connections from remote machines add the -r command line flag.
I thought this thing was cross-platform. Where are the instructions for other platforms?
It is cross platform. What platform are you using?
I agree with “rak” that these instructions could be clearer how to start up on platforms other than Linux.
On Windows, the following works for me:
python “(path to your Python directory)\Scripts\winpdb_.pyw” arg1 arg2 arg3 …
(The quotes are necessary for me because I have a space in my python path.)
DKW, you are correct that the instructions could be clearer for Windows users. However it is such a nuisance typing the path to the scripts folder that I guess most Windows users start Winpdb from the Start menu.
I created a batch file, so I just type “debug” and it launches winpdb with my app loaded. I find the process of repeatedly navigating through directories to attach to the source code for MY app to be annoying, and this allows me to skip it.
Did anyone managed to attach to local process from console?
I am under windows trying this scenario:
c:/temp/test.py contains:
import rpdb2; rpdb2.start_embedded_debugger(”123″)
I run it by double-clicking.
A can attach manually thru gui. But can’t get command line working:
winpdb –attach=test.py –pwd=123 –host=127.0.0.1
All I receive in return is help message…
Thank you!
Is there a way to launch rpdb2 allowing remote connections, but have it start the script without waiting for a debugger console to attach and say ‘go’?
yes, look at the timeout argument