bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use


From: Eric Blake
Subject: bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call
Date: Tue, 19 Nov 2013 11:34:13 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

On 11/19/2013 11:17 AM, Linda Walsh wrote:

>> Well we have the -d option to rm to explicitly do that.
> ---
> Does the posix "remove" call require a -d?

Huh? There is no POSIX remove(1), only remove(3), unlink(2), rmdir(2),
rm(1), rmdir(1), and unlink(1) (using the traditional notation of which
man page section the interface is described in).  GNU's 'rm -d' is an
extension not required by POSIX, but consistent with BSD implementations.

> 
> I thought it made more sense to have rm correspond to remove
> than create another command called remove that called remove.

Sorry, but to change that, you'd have to go back in time 30 or 40 years
to when rm(1) was first written.  People have grown to rely on 'rm(1)'
being a wrapper around unlink(2), 'rmdir(1)' being a wrapper around
rumdir(2), and 'rm(1) -R' being a wrapper around rmdir(2) or unlink(2)
as needed.

> 
> Are you saying that you think it would be better to have a remove command
> that does this?

No, because remove(3) is just a thin wrapper around unlink(2) or
rmdir(2), and most users are already familiar with how to remove files
according to their type.  I see no reason to add a remove(1).

> 
> As for the posix document you pointed at, I'm suggesting doing step 4
> after step 1... same thing posix does, just reordering things a bit.

Sorry, but doing things in rm(1) in a different order than POSIX
describes would lead to subtle breakage to lots of existing scripts.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]