FAQ
This and other RFCs are available on the web at
http://tmtowtdi.perl.org/rfc/

=head1 TITLE

unlink() should be left alone

=head1 VERSION

Maintainer: Nathan Wiger <nate@wiger.org>
Date: 04 Aug 2000
Version: 1
Mailing List: perl6-language@perl.org
Number: 29

=head1 ABSTRACT

Some people have suggested that unlink() is too Unix
centric, that that it should be renamed to something
like delete() or remove().

This should not happen. unlink() should remain unlink().

=head1 DESCRIPTION

While on the surface, renaming unlink() may seem like
a not-too-bad-idea, in reality it has many bad parts:

1. It confuses experienced Perl, C, and Unix programmers

2. It makes link() and symlink() almost non-sensical

3. It's possible to have more than one link to a file
in Unix, meaning unlink() != delete().

4. It's a useless change. It's not broken.

Renaming a function just for the sake of renaming a
function, when in reality it works identically to the
native C counterpart, does not add value to Perl 6.

=head1 IMPLEMENTATION

Nothing to be done!

For those that are adamant about this, I suggest that
they consider writing a module, say "Win32::Synonyms",
that could be composed of typeglobs:

*delete = \&CORE::unlink;

With better referencing in Perl 6 this should be easily
possible. However, I think it's RABID (Really A Bad IDea)
at best.

=head1 REFERENCES

RFC 28 (v1) Perl should stay Perl, by Simon Cozens.
Unix unlink(2) man page

Search Discussions

  • Skud at Aug 4, 2000 at 5:38 pm

    On Fri, Aug 04, 2000 at 05:30:35PM -0000, 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 *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.

    K.

    --
    Kirrily Robert -- <skud@netizen.com.au> -- http://netizen.com.au/
    Open Source development, consulting and solutions
    Level 10, 500 Collins St, Melbourne VIC 3000
    Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
  • Nathan Wiger at Aug 4, 2000 at 5:51 pm

    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
  • Ariel Scolnicov at Aug 4, 2000 at 6:52 pm

    Nathan Wiger 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, 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.
    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.

    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.

    [...]


    --
    Ariel Scolnicov |"GCAAGAATTGAACTGTAG" | ariels@compugen.co.il
    Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz
    72 Pinhas Rosen St. |Tel: +972-3-7658514 (Main office)`---------------------
    Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 http://3w.compugen.co.il/~ariels
  • Johan Vromans at Aug 5, 2000 at 9:40 am

    skud@netizen.com.au 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
  • John Porter at Aug 4, 2000 at 5:44 pm

    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 it?) doesn't mean
    it won't in the future.

    --
    John Porter
  • Myers, Dirk at Aug 4, 2000 at 7:48 pm

    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
  • Spider Boardman at Aug 4, 2000 at 8:39 pm
    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 a directory, and
    unlink() otherwise.

    --
    Spider Boardman (at home) spider@Orb.Nashua.NH.US
    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
  • Damien Neil at Aug 4, 2000 at 11:36 pm

    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
  • Spider Boardman at Aug 4, 2000 at 11:57 pm
    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) spider@Orb.Nashua.NH.US
    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
  • Tom Christiansen at Aug 4, 2000 at 11:58 pm
    Gosh, just unlink() leave it as it is.

    --tom
  • Tim Jenness at Aug 5, 2000 at 12:05 am

    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
  • Russ Allbery at Aug 4, 2000 at 10:19 pm

    Myers, Dirk writes:

    If a remove() is added, it should (IMHO) seek-and-destroy.
    This is impossible on a Unix file system.

    --
    Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
  • Fisher Mark at Aug 4, 2000 at 7:53 pm

    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 fisherm@tce.com
    Thomson Consumer Electronics Indianapolis IN
    "Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_
  • Bart Lateur at Aug 6, 2000 at 10:20 am

    On 4 Aug 2000 17:30:35 -0000, 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 need to be more Unix-centric than Unix itself?

    Do as with for/foreach: make synonyms.

    --
    Bart.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-language @
categoriesperl
postedAug 4, '00 at 5:30p
activeAug 6, '00 at 10:20a
posts15
users14
websiteperl6.org

People

Translate

site design / logo © 2021 Grokbase