On Fri, 5 Jun 2009, Elmar Stellnberger wrote:
Yes that will be a good solution for the usage of cp within shell scripts. However in most cases I invoke cp directly via the command line so that it is somehow awkward and very easy to forget having to issue always an extra command that tests for the return value (i.e. cp && echo xx).
The scenario under discussion was a simultaneous (long-running) cp and "killall -s SIGINT cp". Shouldn't the user expect the POSIX-defined default behaviour for the signal?
It is not possible to create a shell alias for this since testing for the return value must take place right -after- executing cp.
Shell functions allow arguments and multiple commands.
What about nonetheless issuing a message on stderr as long as no -q/--quiet option is given for the cases where the return value becomes nonzero?
Other coreutils as rm are even more verbose than that, so why just solely not cp? Making a difference just on cp will be somehow conterintuitive. > rm hug rm: remove write-protected regular empty file `hug'? y rm: cannot remove `hug': Permission denied
cp does print diagnostic messages to stderr in many cases where the return value is nonzero, e.g. permission errors. It is not an error to terminate immediately on SIGINT however, so I'm unsure it's worthwhile adding such output to cp given that wrapper scripts and shell functions can provide the same feature if so desired.
P.S.: In what kind of situation will it not be adequate to resume copying by issuing the same cp-command again?
cp is not always idempotent, e.g. when using --backup. It's also inefficient to overwrite destination files which already exist; rsync would be better for repeat copies.
Cheers, Phil _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils