87

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'.

3

5 Answers 5

102

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.

9
  • 4
    Looking forward to all the criticism. :)
    – Minix
    May 20, 2015 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. May 20, 2015 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, 2015 at 16:01
  • 3
    this is a rather clever solution, iv learnt something new, bravo +1
    – mike-m
    Feb 28, 2016 at 6:29
  • 1
    This is amazing. I have a lot to dig into and learn from this answer.
    – ccnokes
    Aug 17, 2017 at 4:34
40

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' &
pgid=$!
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
1
  • 5
    undeerrated answer (the method at the bottom). Simple to understand and to memorize. Nov 19, 2018 at 11:15
28

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.

4
  • 4
    If you add wait as the final command (command3 in your example), you can execute clean up code after the user press Ctrl-c. Oct 31, 2018 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, 2021 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, 2021 at 21:19
  • 1
    @jv-dev Might be that find forks itself cleanly away from the parent group. Any process can do that, you cannot force it not to, if I remember correctly. Feb 21, 2022 at 20:38
-1

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.
1
-2

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.

1
  • 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. May 20, 2015 at 21:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .