Use the Bash trap Statement to Clean Up Temporary Files
The trap statement in bash causes your script to execute one or more commands when a signal is received. One of the useful things you can use this for is to clean up temporary files when your script exits.
To execute code when your script receives a signal, use the following syntax:
trap arg sigspec...
The "arg" is the command to execute. If the command contains spaces, quote it. You can include multiple commands by separating them with semicolons. For more complex things, put your exit code in a function and just invoke the function. The "sigspec" list is a list of signals to trap and then execute "arg" (if/when they occur). For example, to remove a file on EXIT, do the following:
trap "rm -f afile" EXIT
Note that EXIT is not a real signal (do kill -l to see all signals); it is synthesized by bash.
Be careful using wildcards in "arg", because if they are unquoted or quoted with double quotes, they get expanded when the trap statement is encountered and not when "arg" is executed. For example, if you have a file named "abc.tmp" and the following trap statement is executed:
trap "rm -f *.tmp" EXIT
the command that gets executed when the script exits is "rm -f abc.tmp" and not "rm -f *.tmp". To avoid this problem, use single quotes.
If you create temporary files at various places in your code and you don't use a naming convention that would allow you to use a wild card in your trap statement and you don't want to worry about changing your trap statement as your code evolves, you could write something like this to allow you to add new trap commands that get executed on exit:
#!/bin/bash
declare -a on_exit_items
function on_exit()
{
for i in "${on_exit_items[@]}"
do
echo "on_exit: $i"
eval $i
done
}
function add_on_exit()
{
local n=${#on_exit_items[*]}
on_exit_items[$n]="$*"
if [[ $n -eq 0 ]]; then
echo "Setting trap"
trap on_exit EXIT
fi
}
touch $$-1.tmp
add_on_exit rm -f $$-1.tmp
touch $$-2.tmp
add_on_exit rm -f $$-2.tmp
ls -la
Here the function add_on_exit() adds commands to an array, and the on_exit() function loops through the commands in the array and executes them on exit. The on_exit function gets set as the trap command the first time add_on_exit is called.
Mitch Frazier is an Associate Editor for Linux Journal.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- What's the tweeting protocol?
- New Products
- RSS Feeds
- Readers' Choice Awards
- Dart: a New Web Programming Experience
- Reply to comment | Linux Journal
12 hours 45 min ago - Reply to comment | Linux Journal
15 hours 17 min ago - Reply to comment | Linux Journal
16 hours 35 min ago - great post
17 hours 10 min ago - Google Docs
17 hours 32 min ago - Reply to comment | Linux Journal
22 hours 20 min ago - Reply to comment | Linux Journal
23 hours 7 min ago - Web Hosting IQ
1 day 41 min ago - Thanks for taking the time to
1 day 2 hours ago - Linux is good
1 day 4 hours ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.



Comments
Bugs in the article's scripts?
First, a caveat: I rarely use Bourne-shell scripts. Still, I was unable to get
the example cited in the article running, and I believe that is caused by at least
two problems in the illustrative example scripts.
It seems to me that the exit commands have to be quoted when add_on_exit
is invoked; i.e., add_on_exit "rm -f $$-1.tmp" instead of add_on_exit rm -f $$-1.tmp ,
no? Also, shouldn't the command be assigned to a new element of the on_exit_items
array using on_exit_items="([$n]=$*)" ?
isohedral
Works for me
The example script works for me.
The exit commands could be quoted when calling add_on_exit but they don't have to be. The entire command line (to add_on_exit) is quoted when it is added to the array:
on_exit_items[$n]="$*"and the commands are added to a new element of the array:
local n=${#on_exit_items[*]} on_exit_items[$n]="$*"The syntax that you suggest for appending to the array does not preserve the existing elements.
Mitch Frazier is an Associate Editor for Linux Journal.
bash script to capture stdin
Hi there, firstly, excellent article!
I am running a script on my ubuntu system to pair my BT mouse with my laptop. I'd like at one to point capture keyboard input to proceed with the pairing. I am running the script graphically by double-clicking the executable, and I do NOT wish to open a terminal.
Is there a way to do this using TRAP? Either to tell the script to wait for a keyboard signal, or maybe call some other program that does so?
Details can be found here:
http://www.linuxforums.org/forum/linux-programming-scripting/150535-abso...
-Thanks!
Keyboard
There's not a "keyboard" trap that you can catch and beyond that since you haven't opened a terminal you don't even have a keyboard "connected" to your script. This is actually an important point: when you run a shell script from a GUI launcher, things aren't as you perhaps expect them to be. If you run ls -la /proc/$$/fd from a terminal window you'll see something like:
showing your stdin/stdout/stderr connected to the terminal.
If however you were to run that same command from a script launced by a GUI launcher you would see something like this:
So all output ends up in your ~/.xsession-errors file and your input (stdin) is not even connected to anything useful. Note that when I said see above, I meant you'd see it in your ~/.xsession-errors file.
That said, seems to me there's a simple solution to this problem: since you don't want to open a terminal why don't you use zenity or something to ask the question in a GUI dialog box, eg:
if zenity --timeout 2 --question --text 'Connect BT mouse? '; then # connect mouse ...or:
zenity --timeout 2 --question --text 'Connect BT mouse? ' if [ $? -eq 0 ]; then # connect mouse ...Mitch Frazier is an Associate Editor for Linux Journal.
Worked like a charm and had
Worked like a charm and had the added side-effect of making my pairing process more robust. I'm not sure why, but for some reason, I no longer need to physically put the mouse in pairing mode (a real blessing) by pressing connect on the mouse!
Thank you!
Thanks kindly! Sorry for the
Thanks kindly!
Sorry for the delay, I had not noticed how swiftly you'd replied!
I think your solution solves the problem, and I do understand the problem better now. If you don't mind, I am linking to here and marking the forum threads closed.
Thansk again!
some excellent references to clarify things a bit
http://www.linuxjournal.com/content/bash-arrays
http://www.linuxjournal.com/content/bash-parameter-expansion
thanks A LOT!
was very useful! thanks a lot for that article.
Works Similarly On Korn Shell, Too
This also works in ksh (Korn Shell), with one exception: the "declare" keyword has to be replaced with "typeset" (ie. "typeset -a on_exit_items").