That's why I explained how I interpreted the original post, but you're right, I was not clear enough.
I assumed that the third party tool issues
rm -rf /* if the user of that tool does not provide any arguments. ONLY this case is catched. The user of that tool may not have any knowledge that he is working on an UNIX system at all because he only sees that tools frontend and may not know what effect is caused by not giving any arguments.
For all other cases I'll quote you:
Quote:
Originally Posted by Don Cragun
UNIX utilities are there to help you get a job done. If you use them correctly, they can do wonderful things for you. If you tell them to do stupid things, you'll get what you asked for.
A user who issues the commands you mentioned in the last reply most likely knows what he is doing - that would not be an accidental use of the rm command.
Edit again: thanks for pointing out the issues in your last paragraph.
In my tests (using GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)) the script compains correctly when there are files in the root directory that contain space or tab characters in their names.
I'm not sure if the race condition can be entirely avoided (given my assumtions about the problem are correct).
The issue with whitespaces in the operand list is caused by my lack of quoting. The last line should read
/bin/rm "$@".