On 14/09/2023 10:56, Jeff King wrote:
On Fri, Sep 08, 2023 at 10:59:06AM +0100, Phillip Wood wrote:
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.
One thing I am not clear on is the convention on who does the process
group and controlling terminal setup. Should Git do it to say "I am
handing off control of the terminal to the editor that I am spawning"?
Or should the editor say "I am an editor which has a user interface that
takes over the terminal; I will control it while I am running".
As I understand it the editor has a controlling terminal (assuming there
is a controlling terminal associated with the editor's session id), not
the other way round. If the editor is launched in the background then it
will receive SIGTTIN when it tries to read from it's controlling
terminal which stops the process unless the process installs a signal
handler.
The latter makes much more sense to me, as Git cannot know how the
editor plans to behave. But as I understand it, this kind of job control
stuff is implemented by the calling shell, which does the tcsetpgrp()
call.
Yes, my understanding is that the shell puts all the processes in a
pipeline in the same process group and calls tcsetpgrp() if it wants
that job to be run in the foreground.
So I dunno. It sounds to me like the "right" thing here is making Git
more shell-like in handing control to a program (like the editor) that
we expect to be in the foreground of the terminal. As opposed to the
"ignore SIGINT temporarily" thing which feels more like band-aid. But
I'm wary of getting into a rabbit hole of portability headaches and
weird corners of Unix terminal-handling conventions.
I'm wary of that too, it has the potential to end up adding a lot of
fiddly code checking if git is in the foreground or background and
propagating SIGTSTP and friends up to the shell. In any case we'd need
the "ignore SIGINT" thing for windows anyway. Ignoring SIGINT and
SIGQUIT in the parent is what system(3) does. As long as git exits
promptly when the interrupted child is killed I think that is
reasonable. Would you be happier if we re-raised the signal once we have
cleaned up any state that needs to be written before exiting?
Best Wishes
Phillip
