For the record, there is a slight weirdness with how git-annex
handles a signal like ctrl-c.

For example:

	joey@gnu:~/tmp/b>git annex copy a b --to origin
	copy a (checking origin...) (to origin...) 
	SHA256-s104857600--20492a4d0d84f8beb1767f6616229f85d44c2827b64bdbfb260ee12fa1109e0e
	        3272   0%    0.00kB/s    0:00:00  ^C
	zsh: interrupt  git annex copy a --to origin
	joey@gnu:~/tmp/b>
	rsync error: unexplained error (code 130) at rsync.c(549) [sender=3.0.9]

Here git-annex exits before rsync has fully exited. Not a large problem
but sorta weird.

The culprit is `CmdLine.startup` in Utility.SafeCommand, which installs
a default signal handler for SIGINT, which causes it to immediatly
terminate git-annex. rsync, in turn, has its own SIGINT handler, which 
prints the message, typically later.

(Why it prints that message and not its more usual message about having
received a signal, I'm not sure?)

It's more usual for a `system` like thing to block SIGINT, letting the child
catch it and exit, and then detecting the child's exit status and terminating. 
However, since rsync *is* trapping SIGINT, and exiting nonzero explicitly,
git-annex can't tell that rsync failed due to a SIGINT by examining the
`waitpid` result.
And, git-annex typically doesn't stop when a single child fails. In the
example above, it would go on to copy `b` after a ctrl-c!

A further complication is that git-annex is itself a child process
of git, which does not block SIGINT either. So if git-annex blocks SIGINT,
it will be left running in the background after git exits, and continuing
with further actions too. (Perhaps its SIGINT handling is a bug in git.)

Now, rsync does have a documented exit code it uses after a SIGINT.
But other programs git-annex runs generally do not. So it would be possible
to special case in support for rsync, blocking SIGINT while running it,
noticing it exited with 20, and git-annex then stopping. But this is
ugly and failure prone if rsync's code 20 changes. And it only
would fix the rsync case, not helping with other commands like wget, unless
it assumes they never trap SIGINT on their own.

Which is why the current behavior of not blocking SIGINT was chosen,
as a less bad alternative. Still, I'd like to find a better one.
--[[Joey]] 

[[!tag confirmed]]

> [[done]], I think this was fixed long ago, git-annex no longer installs a
> sigint handler and I interrupt it all the time and it behaves as I would
> expect and not as shown here --[[Joey]]