[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wish: cp: output some sort of message if copying was interrupted
From: |
Elmar Stellnberger |
Subject: |
Re: wish: cp: output some sort of message if copying was interrupted |
Date: |
Fri, 05 Jun 2009 10:19:44 +0100 |
User-agent: |
Thunderbird 2.0.0.19 (X11/20081227) |
Philip Rowlands schrieb:
> 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
>
Providing a wrapper that checks the return value is not too difficult:
cp() { command cp "$@" || echo "error $? copying files."; }
However outputting an interrupted by keyboard message on SIGINT seems to
be more tricky since installing a signal handler beforehand invoking cp
will not do this job:
cp() { local sigh="$(trap -p SIGINT)"; trap "echo copying interrupted by
SIGINT/Ctrl-C. >&2" SIGINT
command cp "$@" || echo "error copying files.";
trap "$sigh" SIGINT; }
--> same results as with pure cp() from above as any new process will
install its own signal handlers
If the goal(-dir) did not exist beforehand invocation of copy specifying
the --update switch to cp should suffice for a continuation of copying.