Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!usenix!std-unix From: djm@eng.umd.edu (David J. MacKenzie) Newsgroups: comp.std.unix Subject: Re: Query about P1003.2 'cp' utility Message-ID: Date: 17 Aug 90 22:16:13 GMT References: <439@usenix.ORG> Sender: std-unix@usenix.ORG Organization: Free Software Foundation Lines: 29 Approved: jsq@usenix.org (Moderator, John Quarterman) In-Reply-To: ast@cs.vu.nl's message of 17 Aug 90 09:46:37 GMT X-Submissions: std-unix@uunet.uu.net From: djm@eng.umd.edu (David J. MacKenzie) In article <439@usenix.ORG> ast@cs.vu.nl (Andy Tanenbaum) writes: (1) If the destination path exists: (b) If the permissions of the file to which the destination path refers to do not permit writing, actions are performed equivalent to the unlink() #5.5.1[POSIX.1] function call using destination as the path argument, and, if this fails for any reason... Now, this behavior might be correct, but is this effect really intended by P1003.2? Possibly, the user that wish to replace the dstfile entirely (as opposed to overwriting it) should use rm BEFORE calling cp, and the -f option should be used only to suppress interaction with the user. Maybe draft 10 clarifies the situation? In draft 10, cp never ever unlinks files. In draft 10, all -f does in cp is turn off a previous -i. I'm going to object to this on the FSF ballot; I think -f should make it unlink (unconditionally), like it does for mv, ln, and rm, or else not be specified at all in the standard, since it's not existing practice. -- David J. MacKenzie Volume-Number: Volume 21, Number 42