8

Why when I try to delete .. from directory I receive error:

rm: refusing to remove '.' or '..' directory: skipping '..'

And before you ask why I want to do this: Just because.

vadimuha
  • 137
  • https://unix.stackexchange.com/questions/192843/why-doesnt-rm-rf-delete-anything – LJKims Jun 06 '17 at 15:19
  • I don't want to delete parent directory, I want delete link to it, do some sort of trap, directory where you can in and can't out – vadimuha Jun 06 '17 at 15:42
  • 3
    Build your own filesystem that does not have the requirement that every directory contains a link to its parent then. But even if you did, you could still "get out" with cd /explicit/path/here. – DopeGhoti Jun 06 '17 at 15:46

2 Answers2

8

That's a safeguard added to most implementations of rm to work around a misfeature of some shells (including POSIX shells) where rm -rf .* would recursively remove the content of . and .. as well (that was fixed by the Forsyth shell and derivatives (like pdksh), zsh and fish at least¹).

You can use the rm builtin of zsh (a shell that doesn't have that misfeature).

zmodload zsh/files # to load and enable the builtin version of rm
                   # and a few other utilities
rm -rf ..

Alternatively, with BSD or GNU find or compatible, you can do:

find .. -delete

Just to be clear, those delete the content (recursively) of the parent directory (including the current working directory).

If you wanted to unlink the .. entry from the current directory, generally on modern systems, you can't. . and .. are always there as long as the directory that contain them exists and can't be removed. On some filesystems, they're even virtual (are not physical entries in the directory file).

Even if you managed to remove them (for example by using debugfs to edit the content of directories by hand), they would be recreated the next time a file system check (fsck) is done and some applications (like the cd builtin of POSIX shells) even ignore them completely (cd .. shaves one path component off the tail of the current working directory as stored in $PWD regardless of whether there's a .. file in the current directory or not), and POSIX requires .. in pathname arguments given to system calls to mean the parent directory regardless of whether an actual directory entry exists by that name in the current (or corresponding for paths like dir/../whatever) directory.


¹ In version 5.2, bash added a globskipdots option to fix that.

  • "find .. -delete" doesn't work. Deleted everything in my working directory. – Luciano Dourado Jun 29 '23 at 12:06
  • @LucianoDourado, that works exactly as specified. See: Just to be clear, those delete the content (recursively) of the parent directory (including the current working directory). – Stéphane Chazelas Jun 29 '23 at 12:33
  • Yeah, that actually was misuse from my part. But it does excludes everything on the parent directory, although I intended to delete only the hidden files/directories. – Luciano Dourado Jun 29 '23 at 13:08
0

I think the command you want is: rm -rf * I think that rm -rf .* works on hidden files too? Not sure.

But MAKE SURE you are in the current directory you want to run this from. In other words, type pwd or echo $PWD to make sure....

So yep, that will remove all files within the current directory.

I am also certain rm -rf ../* will work, since I have tested that. You can add as many parent directories ("../") as you wish to that.

So basically, just add a "splat" on the end to bypass the stupid security.

Kusalananda
  • 333,661
  • 1
    This does not describe why the error message in the title occurs when trying to remove .., which is what the user asks about. – Kusalananda Jun 26 '19 at 06:35