concurrently: `--success last` does not work while `--success first` does

Expectation Switching the order of two commands while simultaneously switching from --success last to --success first should not change the exit status of concurrently

Observed behaviour --success last does not work as expected when used together with --kill-others

Version 4.1.0

Steps to reproduce Take two commands: sleep 5; exit 0; and sleep 100, and switch their order. With --success first works correctly:

$> concurrently --kill-others --success first 'sleep 5; exit 0;' 'sleep 100'
[0] sleep 5; exit 0; exited with code 0
--> Sending SIGTERM to other processes..
[1] sleep 100 exited with code SIGTERM
$> echo $?
0

With --success last works incorrectly (expected to get exit code 0 same as above):

$> concurrently --kill-others --success last 'sleep 100' 'sleep 5; exit 0;'
[1] sleep 5; exit 0; exited with code 0
--> Sending SIGTERM to other processes..
[0] sleep 100 exited with code SIGTERM
$> echo $?
1

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 1
Comments: 15 (5 by maintainers)

Most upvoted comments

Implemented by #318 which has been released in v7.2.0.

paescuj on May 20, 2022

Does the above help anyone? 🙂

gustavohenke on Jun 29, 2019

Hello all! I’m sorry that I took this long to reply.

I think there’s a misconception with how --success works. From its description:

-s, --success     Return exit code of zero or one based on the success or
                  failure of the "first" child to terminate, the "last child",
                  or succeed only if "all" child processes succeed.
                            [choices: "first", "last", "all"] [default: "all"]

Please pay special attention to the first child to terminate part. Although @sergeyevstifeev showed that he inverted the order of his commands, they are still exiting in the same order.

gustavohenke on Jun 29, 2019