2

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*
Improve this question
2
  • 8
    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, 2011 at 14:49
  • Tom, would that I could upvote that a thousand times.
    – MadHatter
    Jun 13, 2011 at 15:34

5 Answers 5

Reset to default
2

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)

Improve this answer
7

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
real_rm=/bin/rm
rm_opts=""

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
  else
    confirm
  fi
}

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 "$@"
    confirm
    if [ $? -eq 0 ]; then
      $real_rm $rm_opts $@
    fi
  else
    $real_rm $rm_opts $@
  fi

}
Improve this answer
6

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

Improve this answer
2
  • A bash solution is also acceptable; perhaps a small regex match in bash?
    – Adam Matan
    Jun 13, 2011 at 12:47
  • 3
    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, 2011 at 13:20
3

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

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

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

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.

Improve this answer
5
  • 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, 2011 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, 2011 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"
    – Rob Moir
    Jun 15, 2011 at 9:34
  • 1
    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, 2011 at 23:55
  • 1
    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, 2011 at 6:51

You must log in to answer this question.

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