Config option for processes to ignore when confirming close

[lilyball]

Ghostty's confirm-close-surface skips the close prompt by using shell integration to detect when you're at a prompt. I can see the motivation for this for the login shell, though it also means it'll skip the confirmation for subshells which may or may not be desired. But the problem here is it means it won't skip the prompt for anything that doesn't use the shell integration, either because it's an unsupported shell, or because it's running in a terminal multiplexer like tmux/zellij/screen.

Terminal.app accomplishes this same "don't prompt at the shell" feature through a combination of two things:

1. It skips when you're at the login shell¹.
2. It has a profile preference in the Shell tab for other processes to ignore, specified by process name. This list defaults to screen and tmux but is configurable.

That preference for other commands to ignore is the thing that I think would be nice to add to Ghostty (the "login shell" one also seems reasonable too for shells that don't support the shell integration). Having the option to skip terminal multiplexers is nice because closing the window doesn't lose that state, you can just reattach to it in a new window. Being able to include other processes that the user doesn't care about interrupting would be nice too. This does require knowing what processes are controlled by the terminal but I'm assuming that's not hard.

Footnotes

1. I'm not entirely sure how this detection is done. Opening a new window and letting login spawn the shell works. Opening a new window using a custom command and specifying the path to my login shell doesn't. Opening a new window using a custom command and specifying /bin/bash does. In all 3 cases the shell is the child of the login command. It's possible it's consulting /etc/shells here for custom commands, since I didn't bother updating that with my shell. ↩

[mitchellh]

I think both of these suggestions are good improvements to the confirm close logic. I think both of them also likely involve parsing the process tree, or is there some other way I'm missing?

If it is parsing the process tree, I suppose the next question is how it's doing this. "How" here is how its getting updates, now how its getting the tree. Since we own the process tree we should be able to easily use syscalls to get child information. But as far as I know, there isn't an evented way to get notification when new child processes start (there is a kqueue event when child processes end), so there must be some kind of polling happening here.

If it is polling, the question I have is how often and under what conditions...

[mitchellh]

Looks like kqueue may support detecting child spawn:

EVFILT_PROC    Takes the process ID to monitor as the identifier and the
                    events to watch for in fflags, and returns when the
                    process performs one or more of the requested events.  If
                    a process can normally see another process, it can attach
                    an event to it.  The events to monitor are:

                    NOTE_EXIT
                       The process has exited.

                    NOTE_FORK
                       The process created a child process via fork(2) or sim-ilar similar
                       ilar call.

                    NOTE_EXEC
                       The process executed a new process via [execve(2)](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/execve.2.html#//apple_ref/doc/man/2/execve) or
                       similar call.

                    NOTE_SIGNAL
                       The process was sent a signal. Status can be checked
                       via [waitpid(2)](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/waitpid.2.html#//apple_ref/doc/man/2/waitpid) or similar call.

                    NOTE_REAP
                       The process was reaped by the parent via [wait(2)](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/wait.2.html#//apple_ref/doc/man/2/wait) or
                       similar call.

                    On return, fflags contains the events which triggered the
                    filter.

If so, then we'll probably need to update libxev to support this.

[lilyball]

fwiw I do think Ghostty should keep track of the process tree anyway, because I really want it to pick up the Terminal.app feature of actually showing me the list of running processes (Terminal.app sticks this in an info window, and lets you copy data from it or send signals to the process group).

I haven't poked at Terminal.app's list in detail, other than to note that it doesn't list children of tmux, so what I assume it's doing is keeping track of any process whose controlling terminal is it. If it's using kqueue to track spawns, it must also somehow detect if a child calls setsid() to ditch its controlling terminal. I haven't ever looked at terminal devices in great detail so I do wonder if there's not any other way for a terminal to keep track of processes it controls. It's also entirely possible that it simply polls for children.