On Fri, Aug 04, 2000 at 04:39:24PM -0400, Spider Boardman wrote:
> The C (POSIX.1) remove() function is NOT just unlink() in drag.
Not everywhere, at least:
>REMOVE(3) FreeBSD Library Functions Manual REMOVE(3)
...
> The remove() function is an alias for the unlink(2) system call. It
> deletes the file referenced by path.
I unfortunately don't have a copy of either the ISO C standard or POSIX.1
handy at the moment, so I can't comment on what they say about it. Given
that ISO C doesn't say anything about directories, I suspect that this
is conforming C at least.
My opinion on the unlink()/remove() debate: Ignoring our history is
foolish. Why suddenly transform every Perl program that uses unlink(),
which has been valid for over a decade, into one using an outmoded and
deprecated construct? unlink() is, in my opinion, actually clearer
than remove(), for it more accurately specifies what the operation
does.
The opinion that remove() should exist and search-and-destroy all links
to a file is even more foolish. Even if this were somehow practical
on any filesystem in common use, this would be an exceptionally
dangerous and destructive operation. If there is a remove() function,
novices will find it before they come across unlink(). Do we really
want the first file-removal operation they discover to perform such
horrible action at a distance?
I would have no objection to adding remove() as a synonym for unlink(),
or as a unlink()/rmdir() hybrid. It is certainly true that when a
novice goes hunting for a way to remove a file, unlink() is going to
take a while to discover. Why not provide a name that they are likely
to look for quickly? (Especially given the prior art of the C remove().)
- Damien
