Repository navigation
exit CLI debugger automatically #40982
Description
Activity
While it wouldn't solve any output issues, is there perhaps another environment variable that I'm missing to disconnect the debugger automatically when the script exits?
As far as I can tell, there isn't. What's the use case here? I'm having a hard time imagining a situation where it is desirable, much less essential, that
node inspect script.jsnever allow any access to the debugger REPL. Depending on what your needs are, it may be possible to achieve it other ways, I suppose.If adding a feature for this is desirable, it seems like the place to start might be here:
node/lib/internal/debugger/inspect.js
Lines 267 to 272 in 43e1278
I'm having a hard time imagining a situation where it is desirable, much less essential, that
node inspect script.jsnever allow any access to the debugger REPL.Interesting! I'm in the opposite place - I'm sure there is a good use for breaking immediately (perhaps attaching an external tool or something?) but I can't really work out when or why I would need to do that. I wonder if we're coming at the idea of what debuggers are useful for from different angles.
In #40857 (comment) you pointed out that Python, when called with
-m pdb, breaks on the first line. Trying that now, I see that it also restarts the script when the program exits. I've never used Python (or any other language) in that way before. Sounds like there could be a potential workflow of some kind in there for me to try out!In Python I use the debugger like this (without passing any extra arguments):
$ cat break.py print("Hello") breakpoint() print("Bye") $ python break.py Hello > /tmp/hello_node_devs/break.py(3)<module>() -> print("Bye") (Pdb) c Bye $ cat no_break.py print("Hello") print("Bye") $ python no_break.py Hello Bye#40982 (comment) was aimed at recreating this experience in Node.js, both visually and interactively, although it seems now that there might be two patterns of use to consider.
The thing I'm currently working on that brought this to light is running multiple unit test scripts from the command line, although I can imagine wanting this sort of behaviour in all sorts of command line applications. A key thing this provides is a way to conditionally bring up the debugger. A script with randomised input failing every so often is a good example of when I would like to break and inspect deeper. If my code never executes a
breakpoint()/debugger;, I'd want it just to run as if the debugger doesn't exist.Hope that's a bit clearer.
You can get part of the way there with
process.kill(process.pid, 'SIGUSR1')instead ofdebugger(). That won't start the CLI debugger, but it will start the inspector and pause until you connect with your debugger. Then you can run scripts normally (node myscript.jsinstead ofnode inspect myscript.js). I'm not sure if that works for you or if you really need that last mile of having the CLI debugger connected automatically.This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Originally posted by @Spakman in #40857 (comment)
Given this
debugger.js:Running
NODE_INSPECT_RESUME_ON_START=1 node inspect debugger.jscorrectly skips the first line, instead breaking on thedebugger;statement. I'd expect the firstconsole.logoutput to appear directly in STDOUT rather than after the debug shell's<(since thedebugger;statement hasn't been executed yet). While I would find that behaviour cleaner, this isn't really the end of the world since if I'm wanting to step through code then I'm likely a bit less concerned about output correctness.Here's the output from that command:
A bigger issue for me is that the debug shell is both brought up automatically without any
debugger;statements (causing what I'd consider in this case to be malformed output) and doesn't terminate without user input. With thisno_debugger.js, runningNODE_INSPECT_RESUME_ON_START=1 node inspect no_debugger.jsgives this output:Here's the output:
In an ideal world, I'd expect running this
no_debugger.jsscript to behave exactly as if I hadn't passed theinspectargument.While it wouldn't solve any output issues, is there perhaps another environment variable that I'm missing to disconnect the debugger automatically when the script exits?