0

I am calling git clone from a non-interactive bash shell. It is non-interactive because it is launched from a Windows Explorer contect menu. I am running git version 2.20.1.windows.1 on Windows 10 64-bit.

I am running Git/usr/bin/bash -l -e 'myscript' in a Git/usr/bin/mintty window launched from the context menu.

I want to block the user from interrupting the git clone with ctrl-c.

I tried:

set -m
trap '' SIGINT SIGTERM (2 single quotes)
git clone ... &
wait -n
echo $?

The ctrl-c passes through to the git clone which exits. I assume it has a signal handler that exits on SIGINT. I would like to know why this does not work.

I tried:

saved=$(stty -g)
stty -isig
git clone ...
stty "$saved"

The stty fails with "stty: standard input: Inappropriate ioctl for device" because there is no tty for a non-interactive bash shell. So how is the ctrl-c getting to the git clone if there is no tty?

I am testing with git clone, but want to deploy this for git pull and git push. Our developers have caused their local repos to be inconsistent by interrupting a long git pull with ctrl-c.

Any help would be appreciated.

Cyrus
  • 84,225
  • 14
  • 89
  • 153
gitrdone
  • 21
  • 1
  • 5

1 Answers1

0

Processes that handle signals themselves (examples seem to be git, ping and scp) prevent the parent trap from being called.

So this simple example won't fit these purposes:

#!/bin/bash
trap '' SIGINT SIGTERM
sleep 10

This answer suggests using set -m (processes run in separate process group) in a subshell which does not send SIGINT to the the process:

#!/bin/bash
trap '' SIGINT SIGTERM
uninterruptableCommand="git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/"
( set -m; $uninterruptableCommand & wait )

WARNING: the example is a really long-running command. You can still send signals to the process directly (e.g. pkill git).

Jonas Eberle
  • 2,835
  • 1
  • 15
  • 25
  • Sleep does not catch signals. Git does and so does ping for example. Try your example with ping -n 20 google.com. Many other postings confirm this. – gitrdone Feb 02 '20 at 17:45
  • @gitrdone thank you for that correction. I have not thought about that. I updated my answer to break signal delivery to the subprocess. – Jonas Eberle Feb 03 '20 at 14:42
  • Did you happen to notice that I have already tried that in my original posting? – gitrdone Feb 03 '20 at 18:42
  • It requires the subshell IMHO – Jonas Eberle Feb 04 '20 at 07:53
  • I did not catch the () distinction, the & control operator to run a job in the background starts a subshell. I tried the () and the clone is still interrupted by the ctrl-c. I am beginning to agree with @that other guy, that Windows bash or mintty works differently. – gitrdone Feb 04 '20 at 17:29
  • 1
    mea culpa - actually two bash shells were involved, one that emulates a spinner which calls one that initiates the git clone. I put the trap in the child bash and the result was that the parent bash terminated on a ctrl-c and closed the window. In the meantime, the git clone was still running and actually completed. A simple ps -ef told the tale. Moving the trap to the parent bash solved the problem. – gitrdone Feb 04 '20 at 18:42