Bash Sub Shells
When writing bash scripts you sometimes need to run commands in the background. This is easily accomplished by appending the command line to be run in the background with an ampersand "&". But what do you do if you need to run multiple commands in the background? You could put them all into a separate script file and then execute that script followed by an ampersand, or you can keep the commands in your main script and run them as a sub-shell.
Creating sub-shells in bash is simple: just put the commands to be run in the sub-shell inside parentheses. This causes bash to start the commands as a separate process. This group of commands essentially acts like a separate script file, their input/output can be collectively redirected and/or they can be executed in the background by following the closing parenthesis with an ampersand.
As a somewhat contrived example, let's say that we want to start a "server" and then once it's running we want monitor it in the background to make sure it's still running. We'll assume that the server itself becomes a daemon and creates a PID file which we can use to monitor it. When the PID file disappears we assume the server has exitted and we send an email to somebody.
Now you could start the server from the main script and then create a second script that does the monitoring and then execute it in the background from the main script, but you can do the whole thing from the same script:
#!/bin/bash server_cmd=server pid_file=$(basename $server_cmd .sh).pid log_file=$(basename $server_cmd .sh).log ( echo "Starting server" echo "Doing some init work" $server_cmd # server becomes a daemon while true do if [[ -f $pid_file ]]; then sleep 15 else break fi done mail -s "Server exitted" email@example.com <<<CRAP ) 2>&1 >> $log_file & echo "Server started"
With this simple example you could of course just execute the whole script in the background and dispense with the sub-shell part, but that may not work if the script is part of a larger script. It's also nice not to require the user to have to remember to start the script in the background, not to mention having to remember to redirect its output to a log file. And of course there are numerous other things a real world script should do: check to see if the server is already running before starting it, delete the PID file if it's stale, check to see if the server has died without removing its PID file, etc. However, that's the real world, this is the example world.
Mitch Frazier is an Associate Editor for Linux Journal.
|HPC Cluster Grant Accepting Applications!||Jan 28, 2015|
|Sharing Admin Privileges for Many Hosts Securely||Jan 28, 2015|
|Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform||Jan 23, 2015|
|Designing with Linux||Jan 22, 2015|
|Wondershaper—QOS in a Pinch||Jan 21, 2015|
|Ideal Backups with zbackup||Jan 19, 2015|
- Sharing Admin Privileges for Many Hosts Securely
- HPC Cluster Grant Accepting Applications!
- Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform
- Internet of Things Blows Away CES, and it May Be Hunting for YOU Next
- Designing with Linux
- Ideal Backups with zbackup
- Wondershaper—QOS in a Pinch
- Slow System? iotop Is Your Friend
- diff -u: What's New in Kernel Development
- Hats Off to Mozilla
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane