Even if you’re brand new to Terminal, I hope someone has given you this valuable advice:
Be very careful when using the
rmcommand to remove files and folders!
The Unix file and folder deletion tool
is one of the most dangerous commands around. After all, no one likes to obliterate precious files by accident. Today, I’ll show you just how hazardous it can be and walk you through some techniques that will help you work with it safely.
There are two main reasons why you should respect and fear the
command. First off, when you remove an item with
it’s gone for good as soon as you press Return. You can’t fish it out of the trash can if you change your mind. Yes, there’s a (slender) chance you may be able to recover some or all of your deleted files using a third-party program, such as SubRosaSoft’s $90
FileSalvage. (To increase your odds of recovering the files you need to stop using your Mac and immediately run the file recovery utility. The longer you use your Mac after making a mistake, the less chance you have of recovering your data.) But let’s face it, once you
something, it’s likely gone for good. Hasta la vista, data!
The second danger with
is that, being a Unix command, it’s quite literal, and it will do exactly what’s asked—even if the request means the destruction of the very system that
is running on. What does that mean? It means that
is very powerful, with the ability to remove files from anywhere on your machine, and that one small typo could lead to very big negative consequences. Consider the following example:
Assume you were working on something in Terminal in your home folder, and you remembered that your wife wanted you to remove something from her Documents folder. She no longer needed her Work Documents folder, as she had recently changed employers. Being the lazy efficient type of person that you are, you realize that you can do this directly from Terminal, without even changing directories. So you type:
sudo rm -rf /Users/spouse/Documents/Work Documents
flags mean “recursively (
) traverse the folder, removing all files and sub-folders,” and “force (
) removal, ignoring permissions.” You’d have to use both these options, along with
sudo, to remove a folder from another user’s directory.)
Sounds like a fine idea, but as soon as you press Return, you put in motion a very rapid and very painful action—you’ve just permanently deleted your own Documents folder, along with everything in it! Yikes! Of course, you have a recent backup (right?!), so it’s only a minor inconvenience and not a major disaster. But how did this happen, and how can you prevent it in the future?
In the above example, there was exactly one character missing—a single backslash—and that’s what caused the devastation. In Terminal, if you’re referencing a file or folder with a name including a space, you must either enclose its name in quotes, or put a backslash before the space, like this:
"/Users/spouse/Documents/Work Documents" /Users/spouse/Documents/Work Documents
The problem is that Terminal sees the space in your original command, and interprets it as a delimiter—that is, something used to separate arguments on the command line. And the
command accepts multiple files on one input line, as in
rm file1 file2 file3. As a result, your single
command was actually two commands:
rm -rf /Users/spouse/Documents/Work rm -rf Documents
Now, the first
will fail, assuming your spouse doesn’t have a folder simply named
in her Documents folder. However, it doesn’t cause any sort of error message, nor does
stop running just because it can’t find the file or folder you referenced. Instead, it notices the space, and thinks, “Ah, here’s another folder I should delete.”
Since you were working in your home folder, and the Documents folder is a top-level folder within that directory, the
command happily does your bidding and removes it, just as you asked. Poof. All gone. You didn’t really need your dissertation anyway, did you? And since
runs without any feedback or warnings, you won’t know something’s wrong until it’s too late. And all because you left out a simple backslash.
Note: In the example I gave, you would only lose your Documents folder if you were working in your home directory—or if you had a folder named Documents in another folder in which you were working. However, I think you can easily generalize the damage you could cause with simple mistakes.
Disaster Prevention 101
Thankfully, there are some easy steps you can take to save yourself from such disasters. The first, obviously, is to exercise extreme care when using
rm, especially with the
(forced) options. But even with extreme caution, we all make mistakes—nearly everyone I know, myself included, has made at least one stupid mistake with
rm. So beyond common sense, what else can you do?
The Safest Solution
Short of not using
at all, the next best solution is to
rm -i. The
option stands for interactive, and it forces you to manually accept each and every deletion. For instance, if you wanted to remove all the files with a name starting with “MyPic,” you’d do this:
$ rm -i MyPic* remove MyPic1.jpg? y remove MyPic2.jpg? y remove MyPic3.jpg? y remove MyPic4.jpg? y
This is really the safest way to use
rm, but it can get quite tedious—consider a directory with 150 files in it that you’d like to trash. There are, however, other solutions that provide some degree of safety.
The Not Quite So Safe Solution
You can also use the shell’s ability to apply the arguments from the prior command to the current command. So instead of just running
on the folder, first do an
to see if you’re getting what you expected. Then tell
to use the arguments from the
command when it runs.
For instance, if you wanted to remove all the files with a name starting with “MyPic,” you might do this:
$ ls MyPic* MyPic1.jpg MyPic2.jpg MyPic3.jpg $ rm !$
part of this command tells the shell to grab the argument (
) from the last command, and use it with the current command. In this example, that means that
will get the
ls. By using the
command first, you can see exactly what the
command will delete. If the
output isn’t correct, or throws an error, then you’ll see that before deleting the files.
You could also use the
command as a “dry run” for your deletion. Instead of just running
rm MyPic*, try it as
echo rm MyPic*
first. The output will show you what the expanded
command would look like:
$ echo rm MyPic* rm MyPic1.jpg MyPic2.jpg MyPic3.jpg
If everything looks right, hit the up arrow (to retrieve the last command), then move the cursor left and remove the word
Another option you might consider is not using
at all. Instead, use the move command,
mv. Create a special “to delete” folder somewhere on your system, and use
to put everything there first. Then, you can look through the “to delete” directory when you have time, and use
only within that directory—or else check it from the Finder and just use the Finder’s trash. So to replicate the above MyPic example, you’d just do this:
$ mv MyPic* ~/myuser/dump_dir/
This would move all the files that start with MyPic into your dump_dir folder, from where you could later look at them at your leisure, just to make sure only the right files got moved. Once you were sure the proper files had been moved, you could then delete the files.
Handle with Care
My personal use of
really depends on the situation, but I use some combination of the above solutions in various ways. One of my cardinal rules is that I try to
flags with the wildcard (the asterisk). There’s just too much that can go wrong. If I have to do something like that, I’m much more likely to use
to make sure I’m deleting what I intend.
I’ll also use the
switch when I’m using the wildcard within a directory; that way, I can make sure that I’m deleting what I want to delete.
At the end of the day, it’s really up to you how well you protect yourself when using
—it’s a very powerful tool, and (especially when used with
and the recursive and forced options) can do great damage to your system in a hurry. There’s nothing that will prove the value of a good, current backup faster than a misdirected
rm -rf. As Spider-Man so famously learned: “With great power comes great responsibility.”
Note: This article was edited at 9:30am Pacific Time on Friday, December 9th. Edits were for style and content; there were no changes made to the Unix instructions…