Query about P1003.2 'cp' utility
David J. MacKenzie
djm at eng.umd.edu
Sat Aug 18 08:16:13 AEST 1990
From: djm at eng.umd.edu (David J. MacKenzie)
In article <439 at usenix.ORG> ast at 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 <djm at eng.umd.edu> <djm at ai.mit.edu>
Volume-Number: Volume 21, Number 42
More information about the Comp.std.unix
mailing list