On Thu, Feb 20, 2020 at 5:11 PM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 2020-02-21 at 00:12:18, Anthony Sottile wrote: > > On Thu, Feb 20, 2020 at 4:01 PM brian m. carlson > > <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > > 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. > > > > 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) > > Yeah, I think this is the case I was discussing up above, where the > parent process waits for the subprocess to exit. If I modify the foo > function in your hook to also have a "sleep 10", then the parent process > hangs until the child process exits, which again would mean that Git > would hang indefinitely if the hook hung. > > Can you maybe tell us a little more about your use case? What are you > doing in your hook that makes this case come up? Why is your hook > trapping SIGINT? > -- > brian m. carlson: Houston, Texas, US > OpenPGP: https://keybase.io/bk2204 My hook in question is a python process: https://pre-commit.com It doesn't really do all that much on SIGINT but prints "(^C) Interrupted" and offers a crash log when receiving ^C -- this races with the git process terminating and causes terminal spew (sometimes with pretty bad consequences with input breaking until `reset` depending on which thing wins the tty reset race). Anthony
