Linux delete all files in directory




I wanna delete all files and directories including the hidden ones in a directory. How to remove all files from a directory when using a CentOS Linux?


I usually just

  cd ..
   rm $DIRNAME -rv
   mkdir $DIRNAME

Only likely to cause a problem if another process is writing to the dir (or checking it exists) while you are doing this.


Just run:

rm /path/to/dir/*

To delete all files and sub-directories pass the -r option:

rm  -r /path/to/dir/*

To get visual display while deleting all files including hidden one pass the -v option:

rm /path/to/dir/*

To get confirmation pass the -i option to the rm command:

rm -rvi /path/to/dir/*


I thought -rv must be before DIRNAME? why put them in last? Does this work on all version of Linux?


For good measure, as there are always multiple ways to do things, first make sure the files are really what you want to delete:

find /path/to/dir

Like the output? Bring up the command again, and add -delete to the end:

find /path/to/dir -delete

It will delete non-dirs with a simple unlink, directories with rmdir. Add -print to the end if you want to see it deleting everything as it goes. Add any other conditionals find supports if you need them.

Note: I don’t think this works on the BSDs, and certainly doesn’t on Solaris. Using xargs is left as an exercise to the reader.


From FreeBSD find man page (should work on macOS too):

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. The -delete primary will fail to delete a directory if
it is not empty. Following symlinks is incompatible with this

Solaris can be pain, but OP working on CentOS so I guess find with -delete should work


Typically GNU tools accept args anywhere. On CentOS, Debian, and most others, rm is part of the GNU coreutils. There may be some distributions where this is not true–maybe Busybox?

Traditional Unix commands don’t accept args at the end. If you often use BSDs or others, you’ll probably get used to putting them before the, er, positional arguments? I don’t know what you call non-flag arguments.


cool. i just learned find command :smile:

Shell script to delete files older than 30 days

mc is also handy when removing files and/or directories :wink:


Over various versions of Linux I have no memories of having a problem with the order of arguments to most file utilities. rm and cp certainly accept arguments at the end on Archlinux, Ubuntu, and Debian. I can see no reason why it would be different on Fedora/Centos, but not using that distro day to day I can’t tell you for sure.

Notworthy exception: scp does require the arguments to be provided before the source parameter.


Never used mc. it said

-bash: mc: command not found


find is staggeringly useful, but then, Linux(unix) tends to be that way.


To be a little more specific on arguments going before or after the the main arguments, the issue typically is the getopt(3) call. GNU’s libc modifies the “standard” (making air quotes here) so args can be accepted anyplace. But as GNU kinda eschews traditional Unix simplicity and implements everything, which I think is a good thing, it also provides a facility to make getopt behave strictly in a POSIX standard so of way, like the traditional getopt. Sometimes (very rarely) applications may add a restriction on the compile so it acts the traditional way. I really dislike that–you command-line-edit to bring up the previous command, and have to zoom all the way back to the start nearly but not quite, and stick in your argument. GNU tends to infect everything, so you never can be sure what commands on the BSDs or Solaris 10 do until you try them, these days.

The Python getopt class behave the traditional Unixy way, too, unless you tell it not to. But these days, everyone with sense uses argparse. I forget if the command-line getopt behaves that way or not. I tell, you one nice thing about Systemd is not having to go read the man page for getopt(1) to figure out how to write an init.d script. I never did it often enough to memorize, and I had to spend 10 minutes puzzling over it every time.