A question about the recommended usage of rm and --

Let's say I've created two files -i and xx. If I try to remove them with

$ rm *

I get:

rm: remove regular file `xx'? n

And, as explained in How do I remove a file in Linux whose name looks like it's ONLY a hyphen, as in "-" and others, the way of solving this is with:

$ rm -- *

Obviously the problems could possibly be much worse with names called -rf or similar.

So my question is:

Should we systematically use -- in rm commands before anything that is expandable, to avoid unpleasant surprises or exploits?

The reason I ask this is that a while ago I learnt this rm gotcha and then forgot it, until recently that a teammate brought it in again. However I have never seen any recommendations in that sense and being so risky, I wonder if we should have it more present? Should the usage of -- be some kind of scripting and console pattern whenever using rm (and probably other commands)?

  • It would be a good idea but usually isn't necessary. If you would like to make your script more robust I would include it. The -- just means no more options will follow.
    – rubixibuc
    Apr 30, 2012 at 22:24

1 Answer 1


In a perfect world, I guess yes, we should systematically use --. But we all learned to use the rm command without systematically typing --, and typing it costs three extra keystrokes so I don't see it happening. Plus, the -- convention to terminate options hasn't always existed (which is why many people didn't learn about it back when they learned how to use rm).

That being said, when using rm (and other commands) in shell scripts, you definitely should always program defensively. So for example:

rm "$1"    # Remove the file named in the first command line argument

is unsafe and should be rm -- "$1". However,

rm "/var/spool/foo/$thatfile"

is safe, because the contents of $thatfile cannot cause rm to misinterpret its arguments.

In your specific example (rm *), I would probably usually use rm ./* as a safe workaround.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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