Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!mips!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: SGI symlink bug?
Summary: maybe SVR3 vs. BSD?
Message-ID: <62256@sgi.sgi.com>
Date: 14 Jun 90 16:44:27 GMT
References: <9006140634.aa20043@WOLF.BRL.MIL>
Sender: vjs@rhyolite.wpd.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 27

In article <9006140634.aa20043@WOLF.BRL.MIL>, mike@BRL.MIL (Mike Muuss) writes:
> 
> ...[`ln` command sequence]...


Do I understand correctly that you feel it would be better if `ln -s foo bar`
would never succeed if "bar" exists?

Because of the dangers of my typing, I alias "ln" to "ln -i".  I do the
same for rm and mv.  (In the pure SVR3 world, there is no notion of `ln -i`
or `mv -i`.)

I think the reason our `ln -s for bar` kills the target is because `ln foo
bar` and `mv foo bar` are always effective in the SVR3 world.  It seems to
me that `ln` and `ln -s` should be as identical as possible, except in the
nature of the link they make.  It would be bad if `ln foo bar` would
succeed where `ln -s foo bar` would fail.

A convincing argument for changing or not changing the IRIX "ln" would be
an appeal to authority, in the form of POSIX or SVR[34]-SVID chapter and
verse.  As far as I can see, the current IRIX way is least wrong.  What's
more, changing `ln -s` to require that the target not exist would probably
break a zillion scripts and cause a jillion people to complain bitterly and
loudly.


Vernon Schryver, vjs@sgi.com