Re: wish: cp: output some sort of message if copying was interrupted

[Philip Rowlands]

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