I want to run multiple commands (processes) on a single shell. All of them have own continuous output and don't stop. Running them in the background breaks Ctrl-C. I would like to run them as a single process (subshell, maybe?) to be able to stop all of them with Ctrl-C.

To be specific, I want to run unit tests with mocha (watch mode), run server and run some file preprocessing (watch mode) and see output of each in one terminal window. Basically I want to avoid using some task runner.

I can realize it by running processes in the background (&), but then I have to put them into the foreground to stop them. I would like to have a process to wrap them and when I stop the process it stops its 'children'.


To run commands concurrently you can use the & command separator.

~$ command1 & command2 & command3

This will start command1, then runs it in the background. The same with command2. Then it starts command3 normally.

The output of all commands will be garbled together, but if that is not a problem for you, that would be the solution.

If you want to have a separate look at the output later, you can pipe the output of each command into tee, which lets you specify a file to mirror the output to.

~$ command1 | tee 1.log & command2 | tee 2.log & command3 | tee 3.log

The output will probably be very messy. To counter that, you could give the output of every command a prefix using sed.

~$ echo 'Output of command 1' | sed -e 's/^/[Command1] /' 
[Command1] Output of command 1

So if we put all of that together we get:

~$ command1 | tee 1.log | sed -e 's/^/[Command1] /' & command2 | tee 2.log | sed -e 's/^/[Command2] /' & command3 | tee 3.log | sed -e 's/^/[Command3] /'
[Command1] Starting command1
[Command2] Starting command2
[Command1] Finished
[Command3] Starting command3

This is a highly idealized version of what you are probably going to see. But its the best I can think of right now.

If you want to stop all of them at once, you can use the build in trap.

~$ trap 'kill %1; kill %2' SIGINT
~$ command1 & command2 & command3

This will execute command1 and command2 in the background and command3 in the foreground, which lets you kill it with Ctrl+C.

When you kill the last process with Ctrl+C the kill %1; kill %2 commands are executed, because we connected their execution with the reception of an INTerupt SIGnal, the thing sent by pressing Ctrl+C.

They respectively kill the 1st and 2nd background process (your command1 and command2). Don't forget to remove the trap, after you're finished with your commands using trap - SIGINT.

Complete monster of a command:

~$ trap 'kill %1; kill %2' SIGINT
~$ command1 | tee 1.log | sed -e 's/^/[Command1] /' & command2 | tee 2.log | sed -e 's/^/[Command2] /' & command3 | tee 3.log | sed -e 's/^/[Command3] /'

You could, of course, have a look at screen. It lets you split your console into as many separate consoles as you want. So you can monitor all commands separately, but at the same time.

  • 3
    Looking forward to all the criticism. :) – Minix May 20 '15 at 15:28
  • 2
    Thank you. It does exactly what I wanted (the trap command). The solution has to be wrapped in a script for reusability though. – user1876909 May 20 '15 at 15:54
  • @user1876909 Here is a skeleton. The specifics are up to you [1]. Glad I could help. [1] pastebin.com/jKhtwF40 – Minix May 20 '15 at 16:01
  • 3
    this is a rather clever solution, iv learnt something new, bravo +1 – mike-m Feb 28 '16 at 6:29
  • 1
    This is amazing. I have a lot to dig into and learn from this answer. – ccnokes Aug 17 '17 at 4:34

You can easily kill a bunch of processes at once if you arrange to run them (and only them) in the same process group.

Linux provides the utility setsid to run a program in a new process group (in a new session, even, but we don't care about that). (This is doable but more complicated without setsid.)

The process group ID (PGID) of a process group is the process ID of the original parent process in the group. To kill all the processes in a process group, pass the negative of the PGID to the kill system call or command. The PGID remains valid even if the original process with this PID dies (though it can be a little confusing).

setsid sh -c 'command1 & command2 & command3' &
echo "Background tasks are running in process group $pgid, kill with kill -TERM -$pgid"

If you run the processes in the background from a non-interactive shell, then they will all remain in the shell's process group. It's only in interactive shells that background processes run in their own process group. Therefore, if you fork the commands from a non-interactive shell which remains in the foreground, Ctrl+C will kill them all. Use the wait builtin to make the shell wait for all the commands to exit.

sh -c 'command1 & command2 & command3 & wait'
# Press Ctrl+C to kill them all
  • 3
    undeerrated answer (the method at the bottom). Simple to understand and to memorize. – Nicolas Marshall Nov 19 '18 at 11:15

I'm surprised this isn't here yet, but my favorite way of doing this is to use subshells with background commands. Usage:

(command1 & command2 & command3)

Output is visible from both, all the bash commands and conveniences are still available, and a single Ctrl-c kills them all. I usually use this to start a live-debugging client file server and a backend server at the same time, so I can kill them both easily when I want to.

The way this works is that command1 and command2 are running in the background of a new subshell instance, and command3 is in the foreground of that instance, and the subshell is what first receives the kill signal from a Ctrl-c keypress. It is very much like running a bash script with respect to who owns what process and when background programs get killed.

  • 3
    If you add wait as the final command (command3 in your example), you can execute clean up code after the user press Ctrl-c. – dotnetCarpenter Oct 31 '18 at 18:38
  • Really? It doesn't seem to be stoppable. Try this: (find / & find /) and press Ctrl+c, it doesn't stop them. – Jose V Mar 13 at 18:45
  • I checked, and there appears to be a difference in behavior - (find / & find /) won't exit on Ctrl+c, but things like (npm test & npm test) will stop output from both commands on Ctrl+c. I'm guessing it has something to do with how STDIN and STDOUT are processed, but I'm not certain. – jv-dev Mar 17 at 21:19

You can use the semicolon ; or && like this:

cmd1; cmd2   # Runs both the commands, even if the first one exits with a non-zero status.

cmd1 && cmd2 # Only runs the second command if the first one was successful.

You can use a pipe. This will start the commands on either ends of the pipe at the same time. You should be able to stop all the commands with the CTRL-C too.

1st command | 2nd command | 3rd command

If you want to run the commands one after the other, you can use @serenesat's method.

  • This passes the output of the first command to the second one (and so on), which is not appropriate here since the output of the first command is supposed to end up on the terminal. – Gilles 'SO- stop being evil' May 20 '15 at 21:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.