I say this as a Unix weenie, albeit a Unix *user* rather than a Unix
*programmer*. I'm quite used to navigating the Unix filesystem but,
having never braved Unix systems programming, had no conceptual link
between deleting/"rm"ing files, and the term "unlink". It tooks me
quite a bit of
Ariel Scolnicov:
It so happens that remove() is standard C (library) for removing a
file. It therefore makes sense to use *that* name, if any change is
made.
IMHO, it's poorly named (though using remove() at least has the virtue of
not conflicting with/overloading the existing "delete").
5. Other operating systems/ file systems have, or could have
hypothetically, the same operation. I.e. just because NTFS
doesn't have multiple links now (or does it?) doesn't mean
it won't in the future.
NTFS does support hard links right out of the box, although the first
On Fri, 4 Aug 2000 16:33:41 -0700, Damien Neil wrote (in part):
Damien On Fri, Aug 04, 2000 at 04:39:24PM -0400, Spider Boardman
Damien wrote:
The C (POSIX.1) remove() function is NOT just unlink() in
drag.
Damien Not everywhere, at least:
Damien REMOVE(3) FreeBSD Library Functions Manual
Gosh, just unlink() leave it as it is.
--tom
On Fri, 4 Aug 2000, Damien Neil wrote:
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
