July 25, 2011, 5:03 p.m.
posted by juff
Contrary to the usual image of UNIX users being radically technical and without a creative bone in their bodies, we submit that typical UNIX users are immensely creative: They can come up with a zillion inventive ways to avoid the computer altogether and, when forced to sit down to stare the computer in the face, they can come up with a dozen more inventive reasons for why things went wrong. UNIX programmers have written thousands of useful freeware and shareware programs, when they should have been getting some work done. You can make files disappear in lots of ways (either intentionally or accidentally). This section lists the four main ways you can trash files — although you can probably come up with a dozen new and creative ways to do the vanishing act with your files.
Because hard drives are not infinitely large, sooner or later you have to get rid of some files. (Some wag once commented that the only thing that’s standard among UNIX systems is the message-of-the-day reminding users to delete unneeded files.)
The normal way to get rid of files is the rm (for remove) command. Until (notice that we didn’t say unless) you screw up, rm removes only what you want it to. Recall that you tell rm the names of the files you want to remove:
rm thisfile thatfile somedir/anotherfile
You can remove more than one file at a time, and you can specify files in other directories (rm removes just the file and not the directory).
This method is usually pretty safe. The tricky part comes when you use wildcards. If you use a word processor that leaves backup files with names ending in .bak, for example, you can get rid of all of them with this command:
That’s no problem — unless you put in an extra space (Do not type this line!):
rm * .bak
Note the little, tiny space between the asterisk and the dot. In response to this command, UNIX says
rm: .bak non-existent
Uh-oh. UNIX decided that you wanted to delete two things: * and .bak. Because the asterisk wildcard matches every single filename in the working directory, every single filename in the working directory is deleted. Then UNIX tries to delete a file named .bak, which isn’t there. Bad move.
At this point, we recommend that you panic, gnash your teeth, and throw Nerf balls at the computer. After you calm down a little, read the rest of this chapter for some possible ways to get your files back.
You can also make slightly less destructive but still aggravating mistakes when you forget just which files you have. Suppose that you have files named section01, section02, and so on, up to section19. You want to get rid of all of them, so you type this line:
Now suppose that you forgot that you also have a file named second.version, which you want to keep. Oops. Bye-bye, second.version.
The obvious solution is to delete things one at a time. Unless you are an extremely fast and steady typist, however, that’s not practical. In the following sections, we make some suggestions about that, too.
Are you feeling paranoid yet, as though every time you press the R and M keys you’re going to blow away a year’s worth of work? Wait — it gets worse.
The cp, mv, and ln commands can also clobber files by mistake: If you use one of these programs to copy, rename, or link a file (respectively) and a file already has the new name, the existing file gets clobbered. Suppose that you type this command:
mv elbow armpit
If you already had a file named armpit — bam! It’s gone! The same thing happens if you copy or link. (Copying is a little different: If you care, see the nearby sidebar, "Links, copies, moves, truncations, and other details about file destruction.") Here’s an example of the most annoying case of blasting away good files with trash when you use the copy command:
cp important.file.save important.file
As a responsible and paranoid computer user, you want to save a copy of an important file before you make some changes. But your fingers work a little faster than your brain and you get the two names switched (left-handed users are particularly prone to getting names sdrawkcab) — and bam! (again) you just copied an obsolete saved version over the current version. Fortunately, you can arrange your file-saving habits to make this kind of mistake harmless, or at least mostly harmless.
A third popular way to blow away valuable files is by using redirection. If you redirect the output of a command to a file that already exists, whammo! UNIX blows away the existing file and replaces it with your redirected output.
For example, if you type this command:
ls -al > dirlist
Tip If you use the BASH shell, you can give this command:
If you use the C shell, you can give this incantation:
Better yet, get a UNIX wizard to help you include this command in your .cshrc or .profile file so that the command is given automatically every time you start the shell. This command tells the shell to ask you before using redirection to clobber files.
When you redirect output to a file, you can tell UNIX to add the output to the end of an existing file. Rather than type one >, you type two:
ls -al >> dirlist
You have little reason not to use >> every time you think of using >.
The fourth way you’re likely to smash files is in a botched editor session. The problem usually comes up after you have been editing a file for a while and realize that you have screwed up: The changes you made are not what you want, so you decide to leave the editor. On the way out, however, you write the botched changes to the disk and wreck the original file. A similar problem occurs when you use an editor to look at a file: Although you may not intend to change anything, you may make some inadvertent changes anyway. (This can easily happen in emacs, where pretty much anything you type goes straight into the file.) If you’re not careful, you can write the changes to the disk by mistake.
Tip If you use vi, you can avoid the accidental-clobber problem by typing view rather than vi. The view editor is the same as the vi editor (vi and view are links to the same program). The view editor works the same as vi except that it doesn’t let you write changes to the file. Keep it in mind.
Although some versions of emacs can mark files as read-only so that you can’t make changes to the files, the methods of doing so aren’t entirely standardized. In GNU Emacs, you press Ctrl+X, Ctrl+Q in a file window, and Emacs puts an inscrutable %% on the status line at the bottom of the screen. To be even more careful, you can press Ctrl+X and then Ctrl+R to open a file as read-only in the first place.