You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 22, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 22, 2023. It is now read-only.
sending SIGINT or EOF gives unexpected results in node REPL #955
Typing some code then pressing ctrl-c (SIGINT):
>>> some code
KeyboardInterrupt
>>>
Now pressing ctrl-d (EOF) on the empty line will exit the interpreter.
This behaviour is the same in any shell I've used, and many other interpreters and Linux programs that read from standard input. It causes confusion and annoyance for me when I want to quit the REPL, so I press ctrl-c to get to an empty line, then ctrl-d to quit the program (out of habit)... but actually node exits as soon as I press ctrl-c, and then ctrl-d closes my shell.
This seems to work now, but I think I found a bug:
$ node
> user = require('./user');
/.../user.js:52
console.log(User(email, pw);
^
... ^C$ (REPL has exited and I'm back at my shell)
I'm trying to require a module which has a syntax error it. It shows the error message and an ellipses (...). If I press enter, the error message is displayed again. If I press ^D, the REPL exits (this is somewhat unexpected since I'm not on an empty input line). If I press ^C, the REPL exits. I tried reproducing this by typing only the syntactically wrong line of code (without doing a require) but in that case things seemed to work properly.
ok, so I tried this with a few different local modules, and the problem in my latter comment doesn't occur for all local modules, but I can reproduce it by requiring a file containing this:
var redis = require('redis'),
client = redis.createClient();
exports.getUser = function (email, callback) {
client.get(email, callback);
}
after requiring this module, typing something and then pressing ^C actually does works as expected. However, pressing ^D seems to cause the REPL to hang, so that it isn't catching any subsequent SIGINTs. That's why ^C was closing the program in my comment above, I was pressing ^D first.
EDIT: the first problem doesn't seem to be related to the second problem, I can reproduce the first problem when requiring a file which doesn't have the second problem.
Activity
isaacs commentedon Apr 20, 2011
I'm +1 to this.
^Cshould be "break" only, and not "exit", imo.@ry how do you feel about this?
ry commentedon Apr 20, 2011
i'm for it
TooTallNate commentedon Apr 20, 2011
Yes! I was just thinking this exact thing the other day
jnjackins commentedon Apr 26, 2011
This seems to work now, but I think I found a bug:
I'm trying to require a module which has a syntax error it. It shows the error message and an ellipses (...). If I press enter, the error message is displayed again. If I press ^D, the REPL exits (this is somewhat unexpected since I'm not on an empty input line). If I press ^C, the REPL exits. I tried reproducing this by typing only the syntactically wrong line of code (without doing a require) but in that case things seemed to work properly.
jnjackins commentedon Apr 26, 2011
further, just doing this:
results in more weird behavior. On the input line that comes up after that require statement, ^D does nothing and ^C exists the program.
jnjackins commentedon Apr 26, 2011
ok, so I tried this with a few different local modules, and the problem in my latter comment doesn't occur for all local modules, but I can reproduce it by requiring a file containing this:
after requiring this module, typing something and then pressing ^C actually does works as expected. However, pressing ^D seems to cause the REPL to hang, so that it isn't catching any subsequent SIGINTs. That's why ^C was closing the program in my comment above, I was pressing ^D first.
EDIT: the first problem doesn't seem to be related to the second problem, I can reproduce the first problem when requiring a file which doesn't have the second problem.
sh1mmer commentedon Oct 24, 2011
@jnjackins please create a new bug for the second problem rather than reopening a fixed issue.