bug-coreutils
[Top][All Lists]
Advanced

[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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]