Server Fault is a question and answer site for system and network administrators. 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

Is there a way to block rm with a single * in production servers? This would help prevent accidents like:

rm test *

instead of

rm test*
share|improve this question
You're looking for a technical solution to a people problem. I suggest that you do two things. Have a decent backup/restore procedure, and a punishment for careless users. A big stick, or a $100 fine. – Tom O'Connor Jun 13 '11 at 14:49
Tom, would that I could upvote that a thousand times. – MadHatter Jun 13 '11 at 15:34
up vote 2 down vote accepted

Use zsh --- it automatically asks you if you want to delete all the files in a directory.

server:~/dir/processing> rm *                                                                                                                    
zsh: sure you want to delete all the files in /home/wheel/dja/dir/processing [yn]?

(I assume this is a default feature --- I can't find any config options that have been set to turn it on, but I didn't write my .zshrc)

share|improve this answer

Here's a bash function that can be sourced from .bashrc to add a warning when you use rm with more than 2 arguments:

unalias rm 2>/dev/null

function confirm {
  echo -n "Do you want to continue (Y/N)? "
  read v
  v=$(echo $v|tr '[a-z]' '[A-Z]')
  if [[ "$v" == "Y" ]]; then
    return 0
  elif [[ "$v" == "N" ]]; then
    return 1

function rm {

  if [ $# -gt 2 ]; then
    echo "WARNING: You have passed a list of files and directories that is $# entries long!  Is this what you intended?"
    echo "Here is the list of files:"
    echo "$@"
    if [ $? -eq 0 ]; then
      $real_rm $rm_opts $@
    $real_rm $rm_opts $@

share|improve this answer

Not without replacing the shell. rm doesn't even see the * since the shell globs the appropriate filenames before passing them to rm.

share|improve this answer
A bash solution is also acceptable; perhaps a small regex match in bash? – Adam Matan Jun 13 '11 at 12:47
To Ignacio's point, even a bash function or alias doesn't see a * as a passed argument, it sees all files or directories matching *. If you wrote a tiny bash function called rm() that did a for a in $@; do echo $a; done you would see many many lines if * is passed. – Kyle Smith Jun 13 '11 at 13:20

Not a solution, but small workaround. Alias rm as rm -i .

This workaround does not help when flag -f is used.

share|improve this answer
Makes rm test* tiresome. – Adam Matan Jun 13 '11 at 12:48
true, but rm -f test* is solution in that case – bbaja42 Jun 13 '11 at 13:52
+1 Correct, but I fear that my users would automatically use -f. – Adam Matan Jun 13 '11 at 14:19
I agree, and use -f all the time. – bbaja42 Jun 13 '11 at 15:16

You could also provide a special alias that user's who you are concerned will make this mistake can use instead. e.g.

alias rm-test="rm test*"

Again it's more of a work around, but, in general *nix assumes you know what you're doing and mean to do what you say.

share|improve this answer
I've been at companies where this approach has been used unsuccessfully because every time there was a mistake it came back to "Why didn't you use the saferm alias we set up?" -- of course it's too late then :). – Kyle Smith Jun 13 '11 at 14:34
Understood. I'm not saying it's a great option either. However, you've moved the technology problem into a managerial/training problem. Really the original question is too vague to determine if this would be a successful approach. – frogstarr78 Jun 13 '11 at 15:20
One thing that might help the people you're worried about use the "safe alias" is if you mandate that everyone uses it, so it doesn't become a case of singling out people who make mistakes and more of a case of saying "we all make mistakes, we will all use this safety feature" – RobM Jun 15 '11 at 9:34
Better to move /bin/rm to /bin/rm.unsafe then call your 'saferm' wrapper script /bin/rm. Thus no mandating calling non-standard executables or other silliness . – Duane Jun 15 '11 at 23:55
indeed. Very good suggestions. Perhaps I should preface my answer with the notion that it's a way of changing the perspective of the problem, vs providing a technical solution. Just another way of attacking it, improved by @Robert Moir's and @Duane's suggestions. – frogstarr78 Jun 21 '11 at 6:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.