ln(1) and System V

[Rick Ace]

In article <1988Oct31.141701.11055 at utfyzx.uucp>, harrison at utfyzx.uucp (David Harrison) writes:
> Recently Geoff Collyer (utstat!geoff) has pointed out that under System 
> V the command:
> 	ln old new
> will destroy "new" if it already exists.  Historically and under other 
> UNIX versions the same command will complain and refuse to make the link.  
> Geoff calls the System V behaviour "an unintuitive shock". It certainly 
> breaks any program that relies on `ln' refusing to link to "new" as a way
> of doing locks (including parts of Cnews).
>  ...
> I have some questions and one comment on this situation.
> 
> First the questions:  if one re-writes ln (as Geoff has done) to
> reproduce the old behaviour and replaces the SV `ln' in /bin
> with this version what will break?

Don't do this.  Other pieces of the vendor's software likely depend
(or will come to depend in future releases) upon the new behavior
of ln.  If you install your own ln, you waive the right to go back
to the vendor and complain when you have problems; if they ask you
if you're running the software the way it came "out of the box,"
you cannot all honesty answer "yes."

As an anecdote, consider this:  at NYIT, we were running 4.1bsd on
our Vax systems.  Along came 4.2bsd with its new signal(3) semantics.
The change in semantics broke several of our programs, so I charged
ahead and "fixed" signal in the C library to work the way it did under
4.1bsd.  That cured one problem, but others surfaced when I recompiled
some Berkeley programs that had expected to get the new signal.
After a bit of head-scratching, the solution I chose was to restore
the 4.2bsd semantics to signal, implement a new library routine called
v7signal(), and change our software to use v7signal().

If you want something that works like Seventh Edition ln, code it up
and install it under another name, like v7ln.

Rick Ace
Pixar
3240 Kerner Blvd, San Rafael CA 94901
...!{sun,ucbvax}!pixar!rta