Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

exit CLI debugger automatically #40982

Open
Trott opened this issue Nov 26, 2021 · 3 comments
Open

exit CLI debugger automatically #40982

Trott opened this issue Nov 26, 2021 · 3 comments

Comments

@Trott
Copy link
Member

Trott commented Nov 26, 2021

Originally posted by @Spakman in #40857 (comment)

Given this debugger.js:

const hello = 123;
console.log("Expect this to be displayed directly in STDOUT.");
debugger;
console.log("About to exit:", hello);

Running NODE_INSPECT_RESUME_ON_START=1 node inspect debugger.js correctly skips the first line, instead breaking on the debugger; statement. I'd expect the first console.log output to appear directly in STDOUT rather than after the debug shell's < (since the debugger; 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:

< Debugger listening on ws://127.0.0.1:9229/23c5ccc6-0db3-44bb-832d-66f09aa17b83
< For help, see: https://nodejs.org/en/docs/inspector
< 
connecting to 127.0.0.1:9229 ... ok
< Debugger attached.
< 
< Expect this to be displayed directly in STDOUT.
< 
break in debugger.js:3
  1 const hello = 123;
  2 console.log("Expect this to be displayed directly in STDOUT.");
> 3 debugger;
  4 console.log("About to exit:", hello);
  5 
debug> cont
< About to exit: 123
< 
< Waiting for the debugger to disconnect...
< 
debug> .exit

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 this no_debugger.js, running NODE_INSPECT_RESUME_ON_START=1 node inspect no_debugger.js gives this output:

const hello = 123;
console.log("Expect this to be displayed directly in STDOUT.");
console.log("About to exit:", hello);

Here's the output:

< Debugger listening on ws://127.0.0.1:9229/bf6c2802-dfe0-422c-a1a5-7676ee21101e
< For help, see: https://nodejs.org/en/docs/inspector
< 
connecting to 127.0.0.1:9229 ... ok
< Debugger attached.
< 
< Expect this to be displayed directly in STDOUT.
< 
< About to exit: 123
< 
< Waiting for the debugger to disconnect...
< 
debug> .exit

In an ideal world, I'd expect running this no_debugger.js script to behave exactly as if I hadn't passed the inspect argument.

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?

@Trott
Copy link
Member Author

Trott commented Nov 26, 2021

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.js never 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:

if (StringPrototypeEndsWith(
textToPrint,
'Waiting for the debugger to disconnect...\n'
)) {
this.killChild();
}

@Spakman
Copy link

Spakman commented Nov 27, 2021

I'm having a hard time imagining a situation where it is desirable, much less essential, that node inspect script.js never 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.

@Trott
Copy link
Member Author

Trott commented Dec 2, 2021

You can get part of the way there with process.kill(process.pid, 'SIGUSR1') instead of debugger(). 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.js instead of node 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants