reopen 455522 thank you Lucas Nussbaum wrote; > That's not a bug. If you use -i, coreutils always ask you for > confirmation before trying, because it's difficult to do "try to do > that, make all the necessary checks, but finally, don't do it and wait > until I confirm".
Thanks. I agree entirely this rationale in cases where coreutils utilities do not know at the point of asking the question whether the action would succeed if the user said yes. For example in the example you give it would be absurd to require rm to check permissions on /etc/motd before querying the user, particular since said permissions could be changed between the query and the deletion. However in the case in question -- that of `cp -i -l' asking if it should overwrite the destination file -- the current cp code is such that it is already known at the time of querying the user that the link will not be successful. This is because link(2) will never overwrite an existant destination file. For clarity I think this bug should be resolved in one of two ways: a) cp -i -l should not query the user if the destination file already exists, but should proceed immediately to give an error message. or b) cp -i -l should query the user and if the user has said 'yes' then it should unlink the destination before calling link(2). In this case `cp -l' without -i should also unlink before calling link(2) in the event of the destination file existing. Neither of these cases are quite like the operation of cp without the -l flag, but both are more reasonable than the current behaviour and don't involve asking the user a question which never makes any difference to the eventual outcome. Option (b) involves more of a chance to current behaviour -- leaving `cp -l' functionally equivalent to `cp -l -f', so I think that option (a) should probably be prefered. Whatever action is taken the manual page and info documentation should be updated to clearly document the functionality of the -l flag which isn't as simple as implied in the current "link files instead of copying" or "Link files instead of copying them, when possible" because of the difference in semantics between link(2) and the way cp performs a copy. Thanks, J. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
