Prevent bin process from crashing on sigint when sent during npm init dialog

[zemccartney]

Addresses #42

Now, on starting the npm init dialog, we ignore SIGINT on our main process, so when you press ctrl + C (or however else you fire off a SIGINT signal), as that dialog prompts you to do to quit at anytime, instead of the main process exiting, the SIGINT reaches the npm init child process spawned by the new command, which then exits.

[coveralls]

Coverage remained the same at 100.0% when pulling f0126c5 on handle-sigint-npm-init into a1a642d on master.

[coveralls]

Coverage remained the same at 100.0% when pulling 319584e on handle-sigint-npm-init into a1a642d on master.

[zemccartney]

@devinivy heyo! ran into some funkiness here due to signal-handling (or lack thereof) on Windows. To resolve, I'm thinking

1. Skip the test that exercises the newly added SIGINT handling on Windows only
2. Find someone (work, hapi-hour) who has a Windows machine, have them test running the hpal new directly on this branch. I think my changes will actually work when run from a shell i.e. the test failing on Windows isn't actually a problem, but want to confirm

Assuming my changes are even on the right track, how does that plan sound to you?

---

For background / explanation of the above, I think / hope the following are true:

• Assuming this conversation is still current, Windows doesn't understand how to handle SIGINT-ing a child process, which I'd been doing to run this test in a previous commit. Windows handles this by exiting the child process immediately; any process event handlers within the subprocess are skipped and you land in the close handler set on the cli subprocess in run-util.bin

  • as an aside, how I've setup that test to run — killing bin's process group via negative pid — now won't work on Windows for a different reason, that Windows doesn't have an equivalent of Linux's process groups (or at least implements them incompatibly)

• The changes to the new command might be fine on Windows, despite the test being hosed. It sounds like node, under the hood, maps pressing ctrl+c to SIGINT when received in a console environment

• Lastly, maybe unrelatedly, the Travis branch build on my latest commit failed due to an odd EBUSY error on a different test for the new command: https://travis-ci.com/github/hapipal/hpal/jobs/502978134 I'm assuming this is unrelated / a phantom thing, since it didn't affect the PR build off the same commit, but I'll dig into it a bit more, see if Travis' docs speak to the issue at all

  • EDIT Just reran the branch build and it passed

[devinivy]

@zemccartney apologies for neglecting this! I like that plan. But also— I'm down to land this as-is, since it seems like an improvement to me. Do you have any thoughts/guidance on it?

[zemccartney]

@devinivy ah! jeez, yea, I completely spaced here! But I believe someone at my office has a fairly current Windows machine now, I should be able to test this out there, report back. I could shoot to do that this week, which hopefully means just landing this as-is with the assurance that ctrl-c'ing out of the new dialog works as expected on Windows (though could drop in a TODO / peel off a separate issue if any further remediation's needed). Does that work ok?