Red Hat Bugzilla – Bug 70837
Bad rm behavior with broken symlinks
Last modified: 2007-04-18 12:45:15 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020712
Description of problem:
Fileutils 4.1.9 contains a rewrite of rm that interactively queries you if you
want to remove a dangling symlink. If it is not a dangling symlink it simply
deletes it. I find this new behavior with dangling symlinks very annoying and
would like it reverted to old behavior. Fileutils 4.1 from 7.3 has the expected
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. ln -s foo foo
2. rm foo
Actual Results: rm: remove symbolic link `foo'?
Expected Results: Return to prompt
You have rm aliased as 'rm -i', probably because you are logged in as root. The
superuser's .bashrc makes this alias to protect the unwary admin from
accidentally nuking their filesystem. This alias has been in place for a *long*
time, at least since RH6.2.
This only thing new with rm is that it is now a little more descriptive about
the file in question. Before it would simply prompt "rm: remove `foo`?",
whereas now it describes the type of file. For example,
# touch foo2
# rm foo2
rm: remove regular empty file `foo2'? n
# echo foo >foo3
# rm foo3
rm: remove regular file `foo3'? n
If you want to override the alias for a single command, you can quote it
# 'rm' foo3
or you can use the -f option
# rm -f foo
You can remove the alias for a session with the unalias command.
# unalias rm
# rm foo
I would not recommend removing the alias from root's .bashrc. It is a good
think to have in place, and it will probably save your data one day.
Nevermind. I see your problem now. Sorry for the lecture. I guess I just see
too many no-bugs.
Also, should rm describe the file as a broken symlink, rather than just a
symlink. I mean as long is it's telling you when files are empty.....
In non-interactive mode, ie in an executing script, rm should NEVER
query the user for wether or not to delete something.
bug #69713 was probably caused by this change. Scripts should not
IMHO have to force -f in order to delete things.
Fixed in 4.1.9-10