On 08/09/2023 10:59, Phillip Wood wrote:
But I think the right
solution is actually to start the editor in its own process group, and
let it be the foreground of the terminal. And then a ^C while the editor
is running would not only not hit git-commit, but it would not hit any
sequencer or other intermediate processes above it.
I've never done it before, but from my reading we basically want to do
(in the forked process before we exec):
setsid();
open("/dev/tty");
Do we want a whole new session? As I understand it to launch a
foreground job shells put the child in its own process group and then
call tcsetpgrp() to change the foreground process group of the
controlling terminal to that of the child. I agree that would be a
better way of doing things on unix.
It is better for handling SIGINT and SIGQUIT when we don't want git to
be killed but in complicates the handling of SIGTSTP and friends. We'd
need to pass WUNTRACED to waitpid() and then do
"raise(WSTOPSIG(wstatus))" to propagate the signal up to the shell. When
resuming we'd need to call tcsetpgrp() again if git is resumed in the
foreground before sending SIGCONT to the child.
But of course none of that probably has any meaning on Windows. I'm not
sure if there are analogous concepts there we could access with
alternate code, or if it would need to be a totally different strategy.
Lets see if Johannes has any comments about that.
I had a quick google and it looks like cygwin somehow manages to
implement tcsetpgrp() but the windows terminal does not have any concept
of a foreground process group
Best Wishes
Phillip
