UNIX For Dummies [Electronic resources] نسخه متنی

How You Clobber Files

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.

Clobbering files with rm

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:

rm *.bak

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:

rm sec*

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.

Clobbering files with cp, mv, and ln

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.

Creaming files by using redirection

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

and you already have a file named dirlist , it’s gone now, replaced by the new listing.

The cp command does one thing as it clobbers a file;

mv and ln do another. The difference is noticeable only if additional names or links were created for that file with ln . (Refer to Chapter 8 to find out how to create links, or additional names, for files using the ln command.) Clobbering a file with cp : Suppose that you have two files:

first and second . You give second an additional name by using this ln command:

ln second extra.name

Now suppose that you accidentally (who knows why?) type cp first second (remember that you already have a file named second ). What happens to the file named second ? The cp command replaces the current contents of second with a copy of first . That is, it replaces the text (or whatever) that second contains with whatever the file first contains. This change also affects the file named extra.name because it’s another name for the file second . If you use cat or a text editor to look at either second or extra.name , you see a copy of first . The original contents of second and extra.name are gone with the wind.

Clobbering a file with mv or ln : "So what?" you ask, to cut to the heart of the matter. Here’s the interesting part (interesting to us, anyway). If you used mv or ln rather than cp , the second file would not be gone. The mv and ln commands don’t fool with the contents of the file — they just change which filename is connected with which contents. Suppose that you type this command:

mv first second

The mv command disconnects the name second from its current contents. Because the contents are still linked to the name extra.name , that file is still safe and sound. The mv command then connects the name second to the contents of first and, finally, disconnects the name first from the file. Now no file is named first .

As a result, the contents of the second file are not clobbered (to see them, you can use the other name for the file). The ln command works the same way as mv to disconnect filenames and not touch the contents of files.

The message here is that if you have just fouled up an mv or ln command, you may still have the hope of retrieving the old file (if it had other links).

Clobbering files with soft links: To add more confusion, the story is a little different if you use soft links rather than regular hard links. (Refer to Chapter 8 to learn how soft links can link files from different file systems.) Because soft links are just aliases for the true filename, if you do something to the original file, all the links refer to the changed file because it has the same name. On the other hand, if you use cp to change one of the links, the cp command replaces the contents of the original file. The mv and ln commands affect just the link.

Confused? The moral is the same with soft links: After a botched instance of mv or ln , you may still be able to find the original file, if it had another name. It can’t hurt to look.

Tip If you use the BASH shell, you can give this command:

noclobber=1

If you use the C shell, you can give this incantation:

set noclobber

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

Wrecking files with text editors

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.