Maybe handle SIGINT?

[ilkka]

I'm not sure (still sleepy :D) but maybe you should catch SIGINT and pass that through to the children, then e.g. wait for them to handle it and die. You could prompt the user to ^C another time if he wants to not wait and instead send SIGTERM to the children.

[paulerickson]

👍 but it would be nice to have an option for the --kill-others flag to do the same - pass SIGINT to the children and then only SIGTERM after the kill delay.

For example: I start up an http server and run tests - concurrent -k http-server protractor - the tests succeed (exit 0) and so concurrently sends SIGTERM to http-server (exit 143) and returns a final exit code of 1 as if the tests had failed 😦

For my case, I was originally thinking of a new option to return the first exit code as the ultimate exit code. I might make a separate issue or PR for that, but I think this would also fit the bill.

[danilosterrapid7]

Well, according to your comment, I have something that would solve the problem. You might define "-k -s last". In this case, you are saying to the script just take into account the last child process' exit code status.
What I am facing is a bit different. Using this option concurrently is sending "--> Sending SIGTERM to other processes..", but it hangs there without exit it properly.

[paulerickson]

Does it still hang without the --status flag? I would think it has no effect, and the process simply isn't responding to SIGTERM, but maybe I'm overlooking something.

[kimmobrunfeldt]

SIGINT is now passed to children: https://github.com/kimmobrunfeldt/concurrently/pull/43. Will be released as 3.0.0.

For now, you can test this by installing 3.0.0-dev version: npm i -g concurrently@3.0.0-dev.