Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!husc6!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: <12272:Sep916:37:0290@kramden.acf.nyu.edu>
Date: 9 Sep 90 16:37:02 GMT
References: <1215@tardis.Tymnet.COM> <8029:Sep903:04:5390@kramden.acf.nyu.edu> <1990Sep9.140057.15833@mp.cs.niu.edu>
Organization: IR
Lines: 25

In article <1990Sep9.140057.15833@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
> In article <8029:Sep903:04:5390@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >(I think cp foo bar should work like ( rm -f bar; cat > bar ) < foo, so
> >that other links to bar won't be affected; but POSIX 1003.2 apparently
> >disagrees and has cp foo bar work like cat < foo > bar. Oh, well.)
>  Please don't ever implement 'cp' in the way you suggest.  Doing so would
> change file ownership, group, and permissions, not to mention that it would
> fail if the file is in directory for which you do not have write permission.

Which is obviously the sensible solution. Think about what would happen
if files had version numbers: do you really want cp to trash the last
version of the file? Of course not. They're entirely separate versions
and should be creat()ed separately. The fact that they're stored in the
same filename is an accident of creation. (I stole this argument from
comp.std.unix, where this discussion is going on in more depth.)

> It also messes up multiple links and symbolic links to the file.

No; it preserves the multiple links to the original rather than trashing
them, and it leaves the symbolic links with their proper meaning.

Since you can get the write-over behavior with the shell's >, why do you
need it in cp?

---Dan