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 06:45:37 +0100
User-agent: Thunderbird 2.0.0.19 (X11/20081227)

Philip Rowlands schrieb:
> On Sun, 24 May 2009, Elmar Stellnberger wrote:
> 
>>  If I issue a 'cp -a' on one konsole and a 'killall -s SIGINT cp' on
>> another konsole cp -a will terminate just as if it had finished copying.
> 
> Not quite; the exit status passed to the calling process will show the
> signal used to terminate cp. This can in turn be used to diagnose a
> display any desired message, for example in bash:
> 
> $ PROMPT_COMMAND='[ $? -ne 0 ] && echo Command exited abnormally'
> $ true
> $ false
> Command exited abnormally
> 
> Alternatively it would be possible to construct a signal-aware wrapper
> around cp and other interactive processes.
> 
>> My regard would be to let it print something like 'copying interrupted'
>> (... and may be continued by issuing the same command once more).
> 
> As the tools already exist to build this feature it's not a good fit for
> adding to cp. The specific message regarding resumed copies would be
> highly dependent on the arguments to cp.
> 
> 
> Cheers,
> Phil
> 
  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).
  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?
  It is not possible to create a shell alias for this since testing for
the return value must take place right -after- executing cp. A wrapper
shell script however would make things even worse since shell scripts
will as well be invoked fromout of other shell scripts instead of being
applied for user issued commands only.

  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

P.S.: In what kind of situation will it not be adequate to resume
copying by issuing the same cp-command again?









reply via email to

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