Implement wait & cooperative exit on signals (Ctrl-C)

[BugenZhao]

Hi, and thanks for your great project.

I noticed there were many discussions about ctrl-c before (#374), and an option CTRL_C_HANDLING was introduced to offer an alternative behavior which could be suitable for some use cases.

To be honest, whether or not this feature is enabled, the current behavior of cargo-make is not ideal. When a Ctrl-C (or SIGINT) is sent to the process group of cargo-make...

• If CTRL_C_HANDLING is left off, we get cargo-make being terminated immediately, while the currently running command become an orphan and may continue running in the background. Such exit may not be considered "clean" in any circumstances.

  • In interactive shell, we may see logs from child process leaking below the next shell prompt;
  • for non-interactive cases (for example, a docker container running a shell script), there won't be chance for child process to finish its clean-up process (if any), because the container is considered to have finished.

• If CTRL_C_HANDLING is on, we still have problems running interactive commands in cargo make, as described in ctrl+c exits long-running command (REPL) unexpectedly #954. Ctrl-C can be a normal input for the subcommand, but the current implementation always kill it on the second press, which is confusing.

Instead and from my own perspective, cargo-make as a task runner should handle signals like SIGINT and SIGQUIT similarly to a shell. After some investigation, I believe it would be optimal for it to follow the behavior of bash. This approach, known as Wait & Cooperative Exit (WCE), is thoroughly explained in this post: https://www.cons.org/cracauer/sigint.html.

I drafted this PR on those ideas as well. But there might still be some remaining issues to be addressed:

• What should be the ideal relationship between WCE and the previously introduced CTRL_C_HANDLING? Should we retain it, replace it, or directly stabilize WCE if it seems satisfactory to you?

• Shall we make this unix only, as I assume Windows may have completely different convention or implementation?

[sagiegurari]

thanks. 8 know there are many issues in this area. will review it soon