Re: RFC 29 (v1) unlink() should be left alone

On 4 Aug 2000 17:30:35 -, Perl6 RFC Librarian wrote: >Some people have suggested that unlink() is too Unix >centric, that that it should be renamed to something >like delete() or remove(). Gosh, even on a Unix system, the command is "rm" and not something exotic like "ul". Why does Perl nee

Re: RFC 29 (v1) unlink() should be left alone

[EMAIL PROTECTED] writes: > It tooks me quite a bit of camel-petting to find the right function, > when I first needed it. To me, this indicates a severe documentation problem. Remember BASIC? The command to remove a file was KILL. -- Johan

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

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 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 Functi

Re: RFC 29 (v1) unlink() should be left alone

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(

Re: RFC 29 (v1) unlink() should be left alone

Myers, Dirk <[EMAIL PROTECTED]> writes: > If a remove() is added, it should (IMHO) seek-and-destroy. This is impossible on a Unix file system. -- Russ Allbery ([EMAIL PROTECTED])

Re: RFC 29 (v1) unlink() should be left alone

The C (POSIX.1) remove() function is NOT just unlink() in drag. It's something like this (in perl): sub remove ($) { if ( !-l $_[0] && -d _ ) { rmdir $_[0]; } else { unlink $_[0]; } } In other words, it's rmdir() if its argument is

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 firs

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").

Re: RFC 29 (v1) unlink() should be left alone

Nathan Wiger <[EMAIL PROTECTED]> writes: > > 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, a

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 o

Re: RFC 29 (v1) unlink() should be left alone

> While on the surface, renaming unlink() may seem like > a not-too-bad-idea, in reality it has many bad parts: >... 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

Re: RFC 29 (v1) unlink() should be left alone

On Fri, Aug 04, 2000 at 05:30:35PM -, Perl6 RFC Librarian wrote: >=head1 TITLE > >unlink() should be left alone May I suggest that deprecation in favour of a non-platform-specific solution provides: a) backwards compatibility b) less unix-centrism I say this as a Unix weenie, albeit a Unix