Killing a child process returns exit code `0` instead of `null`
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- node.js, typescript
- Domain
- operating-systems
Research direction
The report provides reproducible child.js, cp.js, and pty.js examples; start by running them and comparing node-pty's exit event with Node.js child_process. Trace the process-exit handling used by pty.spawn and verify behavior for signal termination and process.exit(1). Done means the exitCode and signal values are consistent with the documented behavior, with coverage for both cases.
Written by the indexing model from the issue text.
Description
Environment details
- OS: macOS Big Sur
- OS version: 11.1
- node-pty version: 0.10.0
Issue description
I'm testing some things out with node-pty and noticed a difference between how Node.js child_process handles on exit and how node-pty handles them.
I wrote a small example.
child.js
Just a small program that logs tick every second.
setInterval(() => {
console.log('tick');
}, 1000);
cp.js
const cp = require('child_process');
const child = cp.spawn('node', ['child.js']);
child.on('exit', (exitCode, signal) => {
console.log(exitCode, signal);
});
child.kill('SIGINT');
When I run this code, it logs
null SIGINT
So, the exitCode is null here because it was killed with a signal like SIGINT.
pty.js
const pty = require('node-pty');
const child = pty.spawn('node', ['./child.js']);
child.onExit(({exitCode, signal}) => {
console.log(exitCode, signal);
});
child.kill('SIGINT');
Doing the same with node-pty however, gives me the following result
0 2
2 is the numeric value of SIGINT, but the exit code is 0 indicating that the process exited just fine.
The same goes if the child.js kills itself with process.exit(1) for instance, the signal with child_process is null, but for node-pty it's 0.
I'm wondering if node-pty wants to be on par with how child_process works or if this is expected behaviour?
Thanks for the package though, it's awesome :)!
- Dominant language
- TypeScript
- Stars
- 2k
- Forks
- 337
- Avg merge
- 21h 58m
- Merged PRs (30d)
- 3
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/node-pty
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
All issues in microsoft/node-pty
Similar issues
-
S: triage
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
fix(errors): EHOSTUNREACH from a happy-eyeballs connect is reported as a resolver error (STAMP-80) Open
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
snapshot-labs/stamp#666 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
GauravKarakoti/SecureFlow#1070 · 1 comment ·
-
feature:Languages/Translations good first issue ready Web
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
digitalfabrik/integreat-app#4394 ·