Section 12.7.  Removing Files

Table of Contents

12.7. Removing Files

Most of the time, we make files so the data can stay around for a while. But when a file is no longer needed, it's time to make it go away. At the Unix shell level, we'd type an rm command to remove a file or files:

    $ rm slate bedrock lava

In Perl, we use the unlink operator:

    unlink "slate", "bedrock", "lava";

This sends the three named files away to bit heaven, never to be seen again.

Since unlink takes a list, and the glob function returns a list, we can combine the two to delete many files at once:

    unlink glob "*.o";

This is similar to rm *.o at the shell, except that we didn't have to fire off a separate rm process. So, we can make those important files go away that much faster.

The return value from unlink tells us how many files have been successfully deleted. Back to the first example, we can check its success:

    my $successful = unlink "slate", "bedrock", "lava";
    print "I deleted $successful file(s) just now\n";

Sure, if this number is 3, we know it removed all of the files, and if it's 0, then we removed none of them. But what if it's 1 or 2? Well, there's no clue which ones were removed. If you need to know, do them one at a time in a loop:

    foreach my $file (qw(slate bedrock lava)) {
      unlink $file or warn "failed on $file: $!\n";

Here, each file being deleted one at a time means the return value will be 0 (failed) or 1 (succeeded), which happens to look like a nice Boolean value, controlling the execution of warn. Using or warn is similar to or die, except that it's not fatal (see Chapter 5). In this case, we put the newline on the end of the message to warn because it's not a bug in our program causing the message.

When a particular unlink fails, the $! variable is set to something related to the operating system error, which we've included in the message. This makes sense to use only when doing one filename at a time because the next operating system failed request resets the variable. You can't remove a directory with unlink (just like you can't remove a directory with the simple rm invocation either). Look for the rmdir function coming up shortly for that.

Here's a little-known Unix fact. You can have a file that you can't read, write, or execute, maybe you don't even own the filethat is, it's somebody else's file altogetherbut you can still delete the file. That's because the permission to unlink a file doesn't depend upon the permission bits on the file; it's the permission bits on the directory that contains the file that matter.

We mention this because it's normal for a beginning Perl programmer, in the course of trying out unlink, to make a file, chmod it to 0 (so that it's not readable or writable), and check if this makes unlink fail. Instead, it vanishes without so much as a whimper.[*] If you want to see a failed unlink, try to remove /etc/passwd or a similar system file. Since that's a file controlled by the system administrator, you won't be able to remove it.[Section 12.7.  Removing Files]

[*] Some of these folks know that rm would generally ask before deleting such a file. But rm is a command, and unlink is a system call. System calls never ask permission, and they never say they're sorry.

[Section 12.7.  Removing Files] Of course, if you're silly enough to try this when you are logged in as the system administrator, you deserve what you get.

    Table of Contents
    © 2000- NIV