Close confirmation with shell integration does not account for backgrounded tasks

[00-kat]

Describe the bug
The close confirmation does not take into account backgrounded tasks, and only cares about whether the user is currently at a prompt or not. This is much easier to describe using reproduction steps; see below.

To Reproduce
Steps to reproduce the behavior:

1. Run kitty --config NONE. Make sure that you are using a shell which Kitty has shell integration for (I tried all three of Fish, Zsh and Bash using kitty --config NONE --override 'shell=XXX').
2. Run cat in the new Kitty window. Try to close the window. Observe the confirmation prompt.
3. Dismiss the confirmation prompt from step three. cat should still be running
4. Press ctrl+z, or whatever the keybinding to background a job is.
5. Try to close the window. Observe that there is no confirmation prompt.
6. Run kitty --config NONE again, with the same shell as before.
7. Run cat in the new Kitty window, background it (ctrl+z), run fg to bring it back to the foreground, and try close the window. Observe that there is a confirmation prompt, because you are not currently at a prompt.
8. Background the cat from step 7 again (ctrl+z). Run a new cat, and background it as well. Run fg to bring it back to the foreground, and try close the window. Once again observe that there is a confirmation prompt, because you are not currently at a prompt.
9. Background the second cat from step 8 again (ctrl+z). Try close the window one last time, and notice that there is no confirmation because you are currently at a prompt.

Screenshots
Here's a video instead:

recording.mp4

I apologise for going so fast; the video would be too large for GitHub had I gone much slower.

Environment details

Click or tap to unhide the environment details.

kitty 0.39.1 created by Kovid Goyal
Linux sycorax 6.12.12-hardened1-2-hardened #1 SMP PREEMPT_DYNAMIC Sat, 08 Feb 2025 14:16:33 +0000 x86_64
S{PRETTY_NAME} 6.12.12-hardened1-2-hardened (/dev/tty)

Running under: Wayland (Hyprland v0.47.2,) missing: blur
OpenGL: '4.6 (Core Profile) Mesa 24.3.4-arch1.1' Detected version: 4.6
Frozen: False
Fonts:
  medium: JetBrainsMono-Regular: /usr/share/fonts/TTF/JetBrainsMono-Regular.ttf:0
          Features: ('zero', 'cv06', 'cv07', 'cv11', 'cv12', 'cv16')
    bold: JetBrainsMono-SemiBold: /usr/share/fonts/TTF/JetBrainsMono-SemiBold.ttf:0
          Features: ('zero', 'cv06', 'cv07', 'cv11', 'cv12', 'cv16')
  italic: JetBrainsMono-Italic: /usr/share/fonts/TTF/JetBrainsMono-Italic.ttf:0
          Features: ('zero', 'cv06', 'cv07', 'cv11', 'cv12', 'cv16')
      bi: JetBrainsMono-SemiBoldItalic: /usr/share/fonts/TTF/JetBrainsMono-SemiBoldItalic.ttf:0
          Features: ('zero', 'cv06', 'cv07', 'cv11', 'cv12', 'cv16')
Paths:
  kitty: /usr/bin/kitty
  base dir: /usr/lib/kitty
  extensions dir: /usr/lib/kitty/kitty
  system shell: /usr/bin/fish
System color scheme: no_preference. Applied color theme type: none

Config options different from defaults:

Important environment variables seen by the kitty process:
	PATH                                /usr/lib/ccache/bin:/home/kat/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/rocm/bin:/usr/lib/rustup/bin:/usr/lib/plan9/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/opt/rocm/bin:/usr/lib/rustup/bin:/usr/lib/plan9/bin
	LANG                                en_AU.UTF-8
	VISUAL                              nvim
	EDITOR                              nvim
	SHELL                               /usr/bin/fish
	DISPLAY                             :0
	WAYLAND_DISPLAY                     wayland-1
	USER                                kat
	XCURSOR_SIZE                        28
	XDG_DATA_HOME                       /home/kat/.local/share
	XDG_CONFIG_HOME                     /home/kat/.config
	XDG_CACHE_HOME                      /home/kat/.cache
	XDG_CURRENT_DESKTOP                 Hyprland
	XDG_STATE_HOME                      /home/kat/.local/state
	XDG_BACKEND                         wayland
	XDG_VTNR                            2
	XDG_SESSION_TYPE                    wayland
	XDG_SEAT                            seat0
	XDG_SESSION_ID                      1
	XDG_SESSION_CLASS                   user
	XDG_RUNTIME_DIR                     /run/user/1000

Note: I can reproduce this with Bash and Zsh too.

Additional context
One thing to be aware of when attempting to fix this is that disowned jobs should not result in a prompt when closing Kitty.

[kovidgoyal]

Yes, it's not supposed to. A backgrounded task shouldn't prevent close.
Given the way tty devices work backgrounded tasks must never
output/input to the tty device otherwise you get undefined behavior
anyway. Therefore, the only safe way to use background tasks is by
either detaching them from the tty using something like nohup or having
them be a GUI program that anyway doesnt care if its associated tty is
closed.

As such, preventing close in the presence of background processes is not
a good idea.

[00-kat]

Yes, it's not supposed to. A backgrounded task shouldn't prevent close.

👍️

Given the way tty devices work backgrounded tasks must never
output/input to the tty device otherwise you get undefined behavior
anyway.

Apologies if I'm being a little dense, but I don't understand how the fact that backgrounded tasks shouldn't read or write to the TTY is related to whether the TTY should close or not.

[kovidgoyal]

Because a background task cannot safely do IO with the tty, closing the tty while it is running should not affect it, it should keep running. Also if the user is meant to interact with sucha task it must present its own UI since it cannot use the tty device. Therefore, by losing access to the tty the user is not generally prevented from interacting with the task.

[00-kat]

Ah okay, that makes more sense. I have just one more question about that though, if that's fine:

closing the tty while it is running should not affect it, it should keep running

Therefore, by losing access to the tty the user is not generally prevented from interacting with the task.

As far as I'm aware, closing the terminal results in the shell and any child processes of it being killed, so it wouldn't keep running right? So in effect the user is prevented from interacting with the task, because it was killed. Or is it the shell which kills the program and not the terminal?

[kovidgoyal]

It's the kernel that sends SIGHUP to all programs with the tty open when the master half of the tty is closed. And yes this will result in not properly backgrounded tasks closing since the default action for SIGHUP is to exit the program. However as I said for a task to actually be backgrounded safely it needs to detach from the tty anyway, in which case it wont receive SIGHUP. Of course, in reality, most users dont know how to background tasks safely (they use the & shell functionality which is insufficient) so this does happen in practice.

For the record the correct way to background a task is

task & disown

If done like this the background task will not close when the terminal is closed.

[kovidgoyal]

Oh and if we are being pedantic about it, even disown is not fully correct since it leaves the STDIO pipes connected to the defunct tty device. To do this fully correctly one needs to use a wrapper program that redirects STDIO to /dev/null, then does the equivalent of disown and then execs the actual program.

It's actually on my TODO list to add a run-gui kitten which does all this and also implements the XDG activation protocol support so that the launched gui process can take focus correctly under wayland.

[kovidgoyal]

And thinking about it some more there is one usecase where it might make sense to ask for confirmation when backgrounded processes exist. That is when the backgrounded processes are suspended. For example, using ctrl-z in vim to get back to the prompt.

[00-kat]

After your last comment, I just realised that I had misinterpreted your comments all along, oops! Apologies.

in reality, most users dont know how to background tasks safely

Were this to be implemented¹, I want to suggest, if that's fine, that Kitty inform users that they should disown a task that is inhibiting exiting Kitty if they try exit when there are backgrounded tasks, as a way to educate users who were trying to start a GUI application from the command-line incorrectly, similar to Fish:

$ exit
There are still jobs active:

   PID  Command
253503  firefox &

A second attempt to exit will terminate them.
Use 'disown PID' to remove jobs from the list without terminating them.

(Note the last line of the code block.)

Of course, I'm not sure if this would actually look decent from a UI perspective if implemented, so feel free to disregard this suggestion.

Edit: maybe it's possible to detect whether background processes are suspended or still running, so this may not necessarily be useful if that were to be possible.

Footnotes

1. I'm not certain but I'm assuming there is at least a chance of it as you had reopened this issue. ↩

[gibfahn]

I can see this may make sense for some people, but for me background processes are never something I want kitty to consider. I filed #8419