Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is a correct way to clean current directory right?

rm -r * .
share|improve this question
up vote 5 down vote accepted

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.

share|improve this answer
+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). – tjameson Jul 13 '13 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. – AnonymousLurker Jul 13 '13 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). – Mark Bessey Jul 13 '13 at 20:59
@MarkBessey I suggest you put a more visible word of caution (regarding permissions on the directory) into your answer. – guntbert Jul 13 '13 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.

share|improve this answer
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 Jul 13 '13 at 12:46
You're right, thanks. I edited it. – user235731 Jul 13 '13 at 13:05
Is Unix much different from Linux? I can use rm --recursive * .*[^.]* on Linux, and was wondering if this would work on Unix. – Paddy Landau Jul 13 '13 at 13:55
@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. – Michael Kjörling Jul 13 '13 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. – Paddy Landau Jul 13 '13 at 20:40

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

find . \( ! -name . -prune \) -exec rm -rf {} \+
share|improve this answer

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`"
share|improve this answer
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. – tjameson Jul 13 '13 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.

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .