0

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)?

Community
  • 1
qtwo
  • 165

1 Answers1

2

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.

Celada
  • 2,390