Re: why link when have ln

[Paul Eggert]

Jim Meyering <address@hidden> writes:

> I don't know of any case in which one would prefer to use
> link or unlink rather than ln or rm.  Does anyone else?

Suppose one wants to atomically create a hard link G to a file F, and
to fail if G already exists.  The command "link F G" does the trick,
but "ln F G" will succeed if G is an already-existing writeable
directory that does not contain a file called F.

I once ran into a similar situation when I had a symbolic link to one
directory, and wanted to replace it atomically with a symbolic link to
another directory.  E.g.:

$ mkdir dir1 dir2
$ ln -s dir1 symlink
$ ln -s dir2 symlink.new
$ ls -l
total 8
drwxr-xr-x  2 eggert eggert 4096 2004-06-23 12:32 dir1
drwxr-xr-x  2 eggert eggert 4096 2004-06-23 12:32 dir2
lrwxrwxrwx  1 eggert eggert    4 2004-06-23 12:33 symlink -> dir1
lrwxrwxrwx  1 eggert eggert    4 2004-06-23 12:33 symlink.new -> dir2

At this point I want to issue the system call
`rename ("symlink.new", "symlink")' but I can't do this with coreutils mv.
For example, "mv symlink.new symlink" renames symlink.new to
dir1/symlink.new, which isn't what I want.

I think is the sort of thing that the "link" and "unlink" commands is
designed for: when you can't get at the underyling system calls
because "ln" and "rm" treat directories specially.

This issue has come up before, and I vaguely recall someone proposing
a "rename" command to do the same thing for the rename system call
(this would have addressed my situation).  However, this would collide
with Perl's "rename" command.

It might be better to add an option (-D or --no-destdir, say) that
causes ln, cp, and mv to not treat the last operand specially because
it happens to be a directory.  This would be a cleaner solution than
having separate commands.  I've started to code up such an option but
have run into some other issues that I'll address first.