Commands for breakpoints in a .pdbrc file

I'd like to save the commands for a breakpoint in a .pdbrc, something like:

b 81 
commands 1 
pp foo.attr1 
pp foo.attr2 
end 
b 108 
commands 2 
pp bar.attr1 
pp bar.attr2 
end 

This would automate setting the environment for the debugging session. However, this does not work with python -m pdb script.py, because at the line commands 1, the pdb prompt starts and asks me for the commands for the first breakpoint, ignoring what I wrote in .pdbrc; further, it raises a NameError after I type end at the pdb prompt, because of foo.attr1, foo.attr2 and even end开发者_高级运维. The same happens for the rest of the breakpoints, so I end up with them set but not their commands.

What would be the correct way to do this? Is it even possible?

You probably don't want this set every time you use pdb anywhere. My recommendation would be to set up an alias, such as:

alias setup_myproj b 81;; commands 1;; pp foo.attr1;; pp foo.attr2;; end

Then you can run setup_myproj when appropriate.

My first thought was that the command must be defined on one line:

commands 1;; pp foo.attr1;; pp foo.attr2;; end;;

However, it appears that this will only work at the prompt, and you will incorrectly get:

Usage : commands [bnum]
        ...
        end

if you place the line above in a .pdbrc

Looking at pdb.py it appears that the author does not properly handle defining commands in a pdbrc.

I personally would just temporarily place the print lines in the code I was debugging while using pdbrc to save the breakpoints of interest to get around this.

More than ten years later, but, unfortunately, it looks like pdb still does not properly handle the end command when reading commands from a .pdbrc file. There's now a related issue for cpython.

In the meantime, for simple control flows, it may be possible to work around the issue, simply by not using the commands command. For example, you could do:

# set the breakpoints
b 81 
b 108 
# continue to the first breakpoint
continue 
# execute commands at first breakpoint
pp foo.attr1 
pp foo.attr2 
# continue to the second breakpoint
continue
# execute commands at second breakpoint
pp bar.attr1 
pp bar.attr2
...

Obviously this only works in simple cases where you know which breakpoint will be reached next.