I am working through SSH on a WD My Book World Edition. Basically I would like to start at a particular directory level, and recursively remove all sub-directories matching .Apple*. How would I go about that?

I tried

rm -rf .Apple* and rm -fR .Apple*

neither deleted directories matching that name within sub-directories.


5 Answers 5


find is very useful for selectively performing actions on a whole tree.

find . -type f -name ".Apple*" -delete

Here, the -type f makes sure it's a file, not a directory, and may not be exactly what you want since it will also skip symlinks, sockets and other things. You can use ! -type d, which literally means not directories, but then you might also delete character and block devices. I'd suggest looking at the -type predicate on the man page for find.

To do it strictly with a wildcard, you need advanced shell support. Bash v4 has the globstar option, which lets you recursively match subdirectories using **. zsh and ksh also support this pattern. Using that, you can do rm -rf **/.Apple*. This is not POSIX-standard, and not very portable, so I would avoid using it in a script, but for a one-time interactive shell action, it's fine.

  • 4
    I can get find . -type d -name .Apple* to work - it lists all the folders. However, it fails when I add -delete at the end. It just comes back with the usage summary. It's running on BusyBox v1.1.1. Does that make a difference?
    – codedog
    Oct 30, 2011 at 1:33
  • 2
    -delete is not POSIX either. ** was introduced by zsh in the early 90s. It's now (by chronological order of appearance) also in ksh93, fish, bash and tcsh. Sep 10, 2014 at 20:19
  • 8
    +1 for rm -rf **/.Apple* Jul 13, 2016 at 12:37
  • 1
    @codedog, if -delete doesn't work use -exec rm -f {} + instead.
    – Wildcard
    Nov 15, 2016 at 3:36
  • 1
    Can you get find to be verbose as it deletes? I suppose the "globstar" method would do this by adding the -v switch.
    – Demis
    Feb 27, 2018 at 22:02

I ran into problems using find with -delete due to the intentional behavior of find (i.e. refusing to delete if the path starts with ./, which they do in my case) as stated in its man page:


Delete found files and/or directories. Always returns true. This executes from the current working directory as find recurses down the tree. It will not attempt to delete a filename with a "/" character in its pathname relative to "." for security reasons.
Depth-first traversal processing is implied by this option.
Following symlinks is incompatible with this option.

Instead, I was able to just do

find . -type d -name 'received_*_output' -exec rm -r {} +

For your case, it seems that quoting the glob (asterisk, *) was the solution, but I wanted to provide my answer in case anyone else had the similar problem.

NOTE: Previously, my answer was to do the following, but @Wildcard pointed out the security flaws in doing that in the comments.

find . -type d -name 'received_*_output' | xargs rm -r
  • 1
    No good reason to use xargs here. -exec rm -r {} \; or, better, -exec rm -r {} + will do as well without failing on special character filenames. See Why is looping over find's output bad practice?
    – Wildcard
    Nov 15, 2016 at 3:37
  • That's good to know. Not worth a downvote, IMO, since the command still gets the job done, but the performance optimization is appreciated.
    – Pat
    Nov 16, 2016 at 2:05
  • 1
    If it were just a performance optimization I would agree with you, but it's not. It's a security hole. You're not correctly handling files with whitespace in their names, and a maliciously crafted filename will result in data loss. Also see Security implications of forgetting to quote a variable in bash/POSIX shells; some of that is applicable and it may at least give you some idea of the type of issues I'm talking about.
    – Wildcard
    Nov 16, 2016 at 2:22
  • Try mkdir -p $'blah\nDocuments\n/etc\n/home\n/received__output' in your directory and then run the same command again, if you don't believe there's potential for data loss. Or, since the question is about Mac OS, mkdir -p $'blah\nDocuments\n/Users\n/Applications\n/received__output'. (Warning: You WILL delete all your files if you do this. That's kind of my point.)
    – Wildcard
    Nov 16, 2016 at 2:27


shopt -s dotglob           # using Bash
printf '%s\n' ./.Apple*    # test
#rm -rf ./.Apple*    
  • 1
    dotglob is useless here. See this page for an example of what dotglob does. Nov 21, 2011 at 2:34

What is possible is that there is nothing wrong with your rm/find command, but that the user you are logged in with doesn't actually have delete permissions. Use ls -l to list things with their permissions, and you can identify who you are with the id and groups commands (either should be available). If you are the "wrong user" to do this, you would need to either change the permissions/ownership of the files, or switch to another user.


Simple command:

rm `find ./ -name '.Apple*'` -rf

Good luck!

  • 6
    This is extremely error-prone, find has -exec key. Nov 20, 2011 at 14:46

You must log in to answer this question.

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