Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!uunet!aplcen!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.shell
Subject: Re: How to do <cmd> file | hold file
Message-ID: <15472:Sep1015:27:3190@kramden.acf.nyu.edu>
Date: 10 Sep 90 15:27:31 GMT
References: <1990Sep9.140057.15833@mp.cs.niu.edu> <12272:Sep916:37:0290@kramden.acf.nyu.edu> <HKS5I=B@xds1.ferranti.com>
Organization: IR
Lines: 24

In article <HKS5I=B@xds1.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
> In article <12272:Sep916:37:0290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> > No; it preserves the multiple links to the original rather than trashing
> > them
> Which is what it should do. Let's say the file in question is "/bin/smail"
> and the link to it is "/bin/rmail"...

It's not my fault you're running an obsolete system without symlinks or
a proper install program.

  [ editor ]

Of course the editor should use write-over, as it's conceptually
modifying the *same* file. cp is putting a *different* file into the
name previously used for the original.

> > Since you can get the write-over behavior with the shell's >, why do you
> > need it in cp?
> Designing for the common case. You can get the uncommon case by doing
> an "rm" first, so why do you need it in cp?

Okay, these arguments cancel themselves out.

---Dan