Just got bitten by the frankly unintuitive behavior of pdb usurping stdin, making it incompatible with debugging a script that reads from stdin.
Would it be difficult to add an option to pdb to bind to the terminal directly?
There is no such thing as “reading directly from the terminal”: all communication with the terminal goes through stdin/stdout which flows through the TTY driver and then into the terminal emulator program - (unlike MS-DOS programming back in the 90’s which could use the BIOS calls or direct memory access to the screen and bypass the O.S. entirely)
What you have, available, is PDB wrappers that will allow debugging through other streams than STDIN - you then connect to it through another terminal or tab: 3rd party packages that do that exist.
This one works for me:
Otherwise, with Python 3.14 and the goodnes implemented via PEP 768, we could say that “Guido’s Time Machine is at it again” - and you will be able to connect and debug your running Python code from another terminal tab, with no external tools other than PDB.
With a Python 3.14 beta build you can already do, from another terminal tab python -m pdb -p PID (PID being the process number of the running program you want to debug)
At least on the unix systems / terminal emulators I’m familiar with, it is possible to interact directly with the terminal via the /dev/tty* character devices. For example:
$ echo 1 | python3 -c 'print("from stdin:", input()); x = open("/dev/tty", "r").readline(); print("from terminal:", x)'
from stdin: 1
2
from terminal: 2
1 Like
Sorry, but there very much is, in all modern OSes. The Perl debugger does this and will happily debug scripts that read from stdin.
Sorry, but there very much is, in all modern OSes. The Perl debugger does this and will happily debug scripts that read from stdin.
How is that done? I pretty much would like to know it. Do you have a side channel to the tty?
(I’m probably botching the unix terminology)
As I understand it, yes, the side channel is just a different file descriptor. Keyboard input from the terminal is made available as a tty / character device in the OS. Often, you’ll have that device be attached to stdin (file descriptor 0). But if stdin if used for something else, there’s nothing stopping the process from opening the same tty device at a different file descriptor, say 3. Everything else is the same; the program just needs to know to read from fd 3 instead of fd 0.
On a unix system, opening gets you the process’s controlling terminal, which is usually the one from which it was started, either directly or indirectly.
On unix, /dev/tty represents the “controlling terminal” of a process, independent from stdin, assuming there is one. See tty(4) — Linux manual page. Not all processes have a terminal, but it’s a pretty safe bet that if you’re using pdb you’re at a terminal.
On Windows, the local terminal is the CON: device. Cygwin provides a /dev/tty that is mapped to the terminal as well.
So, in order to enable debugging of Python scripts that read from stdin, I argue that pdb should have an option to read from the console instead of stdin. I’d even go so far as to argue for this to be the default.
I’d be really interested to know if there are any use cases for driving pdb from piped input as opposed to typing commands at the console.
In OPs case it seems the script takes inputs from stdin. Given that’s a support invocation method, it would make sense for pdb to support it.
In OPs case it seems the script takes inputs from stdin. Given that’s a support invocation method, it would make sense for pdb to support it.
I’m not sure how to interpret your comment. What is a “support invocation method”?
Are you agreeing with me (the OP) that pdb should take its interactive input from /dev/tty, and thus support debugging of scripts that use stdin for their own data?
Yes.
If I can start a script like this python script.py < inputs.txt then I should be able to do python -m pdb script.py < inputs.txt
I’ve never tried to do it but I find it surprising we cannot. I would expect it possible given that the following work
python script.py…python -m pdb script.py
python -m json.tool…python -m pdb -m json.tool
To further this, I’ve been surprised that the following doesn’t work when i tried python -m pdb -c 'print(0)'
I’m speaking less on how the feature should be implemented and more that it should be supported.
(post deleted by author)
Yes. Apologies
I’m really surprised this hasn’t come up, I couldn’t find much on this problem.
Do you (or anyone reading this) know the procedure to get the attention of the developer(s) responsible for pdb to see if this could be considered?
No but I asked a question about a long standing issue for pdb a while back as there was no listed maintainer for pdb. I didn’t get any replies but then @gaogaotiantian resolved it some time later.
Maybe you can get lucky, he’s seemed most active in maintaining pdb the past year or so.