On Thu, Feb 20, 2020 at 4:01 PM brian m. carlson
<sandals@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On 2020-02-20 at 21:14:55, Anthony Sottile wrote:
> > Here's a small example:
> >
> > ```bash
> > #!/usr/bin/env bash
> > foo() {
> > echo zzz part 2
> > sleep 1
> > echo exiting now
> > }
> > trap foo SIGINT
> >
> > echo zzz part 1
> > sleep 10
> > ```
> >
> > ```console
> > $ git --version
> > git version 2.25.GIT
> > $ git commit --allow-empty -m foo
> > zzz part 1
> > ^Czzz part 2
> >
> > $ exiting now
> > ```
> >
> > - I pressed ^C during the first sleep
> > - control was returned back to my terminal
> > - the hook script was still running in the background
>
> I believe the way that SIGINT works on a terminal is that it sends the
> signal to all processes in the foreground process group. So my guess of
> what's happening here is that Git and your script both get SIGINT, Git
> cleans up and exits quickly, leaving your script running.
>
> If so, I'm not sure that Git can do much here. If Git waited for the
> hook to exit, then a broken or hung hook would cause Git to hang
> indefinitely, which is not what the user intended when they pressed
> Ctrl-C. Usually what the user wants is an immediate return to the
> terminal in such a case, and I think most users would consider it a bug
> if Git were to wait for its children.
>
> Certainly I'm open to hearing other views on this, though.
> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204
Taking git out of the situation:
Create a shell script:
```bash
#!/usr/bin/env bash
.git/hooks/pre-commit
```
```console
$ ./t.sh
zzz part 1
^Czzz part 2
exiting
$
```
that works fine (and is the expected case for `subprocess` calls for
example in python)
Anthony
