Re: RFC 29 (v1) unlink() should be left alone
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 camel-petting to find the right function, when I first
needed it.
From a user level, it might seem odd ("Where's rm?"). However, there is
one key distinction here: A Perl program runs file operations at a
system level. It needs to be able to handle everything the system can.
I am open to the possiblity of *adding* a remove() command if it had a
different fundamental ability from unlink(). For example, one could make
remove() remove *all* the links for a file, whereas unlink() only
removes one.
However, I think something like this really belongs in a module, like
this one:
http://www.perl.com/CPAN-local//authors/id/G/GA/GABOR/File-Remove0.20.readme
-Nate
RE: RFC 29 (v1) unlink() should be left alone
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"). Regarding the existence of multiple links -- That is probably an implementation detail of the platform on which the library is running. Since all remove() does is break the association between the name and the contents, links are a red herring. No, remove() is a red herring, because it's only guaranteed to unlink() the file, not actually remove it :). This is *why* I think it's poorly named (on at least some platforms). If you're going to provide a way to remove() (or delete(), or nuke(), or abolish(), or whatever word it goes by) a file, the file should either go away or you should get an error. If all the call does is break a link... you're unlink()'ing, not remove()'ing, and using unlink() to be explicit about what's going on is a Good Thing. If a remove() is added, it should (IMHO) seek-and-destroy. No, that's not what the existing C function does... but if we're requiring people to be aware of C functions, why not just stick with unlink()? (At least if there aren't hordes of people out there who use perl who are aware of the standard C libraries but who aren't familiar with standard Unix syscalls. I suspect this is the case, but may be wrong.) Overall, though, my main objections to changing unlink() are that (a) a suitable replacement isn't obvious (to me, anyway ;) ) and (b) I don't see any clear point at which to stop renaming things -- if we change unlink(), shouldn't we also change chmod() and chown()? Should we change STDIN to INPUT and STDOUT to OUTPUT and STDERR to ERROR ? Although this is probably way more discussion than the subject warrants, so I'll shut up now. Dirk Myers
RE: RFC 29 (v1) unlink() should be left alone
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 versions didn't come with tools for setting up the links (except for the POSIX subsystem tools). I don't know what tools NT comes with now for making hard links, actually, as I use MKS Toolkit on NT which provides ln(1) among its many Unix-compatible commands. === Mark Leighton Fisher[EMAIL PROTECTED] Thomson Consumer ElectronicsIndianapolis IN "Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_
Re: RFC 29 (v1) unlink() should be left alone
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 REMOVE(3) Hmm. OK, the reference I have is a combined one for UNIX95, so this may be a question of XPG-only or of *which* POSIX.1 (199309 or 199506), but at least *some* versions of remove(3) are not simply unlink(2) by another name. -- Spider Boardman (at home) [EMAIL PROTECTED] The management (my cats) made me say this.http://www.ultranet.com/~spiderb PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89 F6 B2 C2 A0 1C AB 1F DC
Re: RFC 29 (v1) unlink() should be left alone
Gosh, just unlink() leave it as it is. --tom
Re: RFC 29 (v1) unlink() should be left alone
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 opinion, actually clearer than remove(), for it more accurately specifies what the operation does. I agree with this. Changing the name of a function without any gain in functionality seems a bit mad. localtime is under "attack" for specific reasons unrelated to its name. When I first started perl (coming from Fortran) I also had trouble sifting through the docs working out how to remove a file but once I knew it was unlink I simply used it because that was the perl command for "rm". -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
