This is a correct way to clean current directory right?

rm -r * .

5 Answers 5


I normally just move one level up in the hierarchy, then remove the directory by name and recreate it:

cd ..
rm -rf dirname
mkdir dirname
cd dirname

because that eliminates the error case of using rm -rf * in the wrong directory.

Note: If the directory has non-standard permissions or is owned by some other account, then you'll lose that when you delete and re-create the directory. That's not something that comes up very often for me, but it's worth thinking about.

If I needed to do this in a script, I'd probably make a function that saves the current directory, moves up a level, deletes and creates the new empty dir, and moves there.

  • +1 It also eliminates the possibility of overflowing the command-line args. IIRC, you can only have 1k bytes for cmd args, so rm * may expand to more than that. Recreating the dir IMHO is the best option (unless you have hardlinks, but that's just dirty).
    – beatgammit
    Commented Jul 13, 2013 at 18:31
  • I'm not sure this approach guarantees that dirname is created with the same permissions/ownership it had before you deleted it, might be a good idea to check for that before deleting. Commented Jul 13, 2013 at 18:53
  • @AnonymousLurker, I did mention the permissions issue. This is the 90% solution for me - I rarely have directories with odd permissions (at least compared to the number of directories with weirdly-named files). Commented Jul 13, 2013 at 20:59
  • 1
    @MarkBessey I suggest you put a more visible word of caution (regarding permissions on the directory) into your answer.
    – guntbert
    Commented Jul 13, 2013 at 21:22

No, and for several reasons: 1) that command will try to remove ., which is the current directory, and will thus fail; 2) that command will not remove "hidden" files that begin with a '.' character; 3) the command will not remove directories.

You could use rm -rf *. This will remove all files and directories, but it will not remove the dotfiles. You could use find . -type f | xargs rm to remove all files including hidden ones, but this won't remove directories.

So, you can use this:

$ find . -print0 -type f -o -type d -not -name '\.' | xargs -0 rm -rf

Here you recursively find all files and directories (as long as they are not called '.') and then remove them. The -print0 and -0 arguments allow it to correctly handle filenames with whitespace in their names.

  • 2
    This code won't delete all items. Just think of an item with a space in its name. So better use -print0 with find and -0 with xargs.
    – Shi
    Commented Jul 13, 2013 at 12:46
  • Is Unix much different from Linux? I can use rm --recursive * .*[^.]* on Linux, and was wondering if this would work on Unix. Commented Jul 13, 2013 at 13:55
  • 1
    @PaddyLandau That's not a comment to this answer, really; it's a separate question. And "Unix" is a very broad term, encompassing everything from HP-UX and AIX to Mac OS X. That said, it looks to me like that rm command would remove all non-dot-files, and all dot-files which contain at least one non-dot character. Try touch ... (yes, three periods), then running it.
    – user
    Commented Jul 13, 2013 at 14:22
  • @MichaelKjörling — thanks, but I was offering this as an alternative. I wasn't sure if it would work on Unix (I use Linux), which is why I posted a comment instead of a separate answer. If it works on Linux, I'd consider it a simple answer. BTW, touch ... does indeed create a hidden file called ... in Linux. Commented Jul 13, 2013 at 20:40
  • @PaddyLandau ...which your rm command doesn't delete (I just tried it).
    – user
    Commented Jul 13, 2013 at 21:43

You can do this, if the -mindepth and -delete switches are available:

find . -mindepth 1 -delete

If you want to stick with POSIX, you can do this (as seen on unix.com):

find . \( ! -name . -prune \) -exec rm -rf {} \+

One easy solution if you don't want to use find is to remove the current directory then recreate it:

rm -rf "`pwd`" && mkdir "`pwd`" && cd "`pwd`"
  • You'd probably want to cache pwd. I'm not sure if this would work properly after you delete it. _dir=$(pwd) ; rm -rf "$_dir" && .... Haven't tested it though, so I could be wrong.
    – beatgammit
    Commented Jul 13, 2013 at 18:26

If you're using bash (version 4 or above), you can use the dotglob shell option to include filenames beginning with a dot in your glob.

shopt -s dotglob
rm -r -- *

The above will break on directories containing many hundreds of thousands of files; in that case, you could use printf (which, being a bash builtin, laughs in the face of ARG_MAX) and xargs (which will supply a safe number of arguments to rm).

shopt -s dotglob
printf '%q ' * | xargs rm -r --

You can unset dotglob once you are done with:

shopt -u dotglob

Another way of doing it without messing around with shell options would be:

rm -r -- * .[^.]* ..?*
##  or
printf '%q ' * .[^.]* ..?* | xargs rm -r --

The first glob * will match everything in the current directory that doesn't begin with a dot; the second one .[^.]* matches everything that begins with a dot, followed by a single non-dot character, followed by any number of other characters; the third glob matches two dots, followed by any one character, followed by any number of other characters. This could be useful if you're stuck in a shell without a dotglob option; however, in such a case printf may not be a shell builtin, or may lack the %q flag (which quotes all the spaces and unusual characters in the arguments fed to it, making them safe to pass to xargs), so you should probably use one of the find-based solutions in such a case.

  • If you have a huge directory listing, this could fail because of the number of CMD args.
    – beatgammit
    Commented Jul 13, 2013 at 18:33
  • @tjameson yes, though that would have to be a pretty huge number of files...
    – evilsoup
    Commented Jul 13, 2013 at 18:50
  • I ran into that just this past week at work. It was something around 500,000 files...
    – beatgammit
    Commented Jul 13, 2013 at 22:43
  • @tjameson ...well, OK then, I'll edit in a disclaimer
    – evilsoup
    Commented Jul 14, 2013 at 8:41

You must log in to answer this question.