On 11/15/2013 3:57 PM, Rick Varney wrote:
Branko Čibej <brane <at> wandisco.com> writes:
It really depends on what you think "Unix rm" actually is. The
unlink() or remove() functions don't care about permissions on the
target, only that you have write permission on the parent directory.
It does not surprise me to hear that system functions don't care about file
permissions. The OS flavor I'm most familiar with is rhel5. Here is how
the interactive rm command behaves in this case:
$ ll foo.txt
-r--r----- 1 usb00219 nxp 4 Nov 15 15:42 foo.txt
$ rm foo.txt
rm: remove write-protected regular file `foo.txt'? y
So while rm is perfectly capable of removing the read-only file in a
directory where I have write permissions, it politely asks first. I had
assumed the rm command behaves similarly on many flavors of Unix (as well as
Linux).
This is probably due to an alias set up in your login script, e.g.
.bashrc. Type "alias" at the command prompt; you will probably find
that "rm" is aliased to "rm -i", which prompts before removing files.
"rm" does not prompt like this by default.
"ll" is not a Unix/Linux command either, so it's a pretty safe bet that
you have aliases set up, either in the distro you have installed, or
configured by your sysadmin (on my CentOS machines, this alias is
present only for the root account by default). Try "\rm foo.txt"
(backslash before executable name); I'll bet that it does not ask you
for permission to remove a write-protected file.
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
