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
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 dcchapman_at_acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
Received on 2013-11-16 01:48:02 CET