ble.sh: [kitty] Hangs on exit

Just updated, I will let you know if this fixes it. Thank you!!!

I discovered that it is possible to add O_CLOEXEC to the specified file descriptor in pure Bash. It hacks the file descriptor that Bash internally uses to back up the original file descriptor for redirection. I implemented it in commit 785267e18c81ada61fb26a346339613a8a8b04e6. The trick only works in Bash >= 4.0, but I think it should be fine for most users. Now I think the hanging tab would happen less.

@10b14224cc @ribru17 Could you update ble.sh by running ble-update and use it for a while to see if the situation changes?

I think the culprit in @10b14224cc’s environment is hyprpaper. First, there are only two processes that started after the hanging session starts (21265) and before running ps uxf (24438):

[murase@letsnote2019 0 a]$ awk '21265 <= $2 && $2 < 24438' c.txt
USERNAME   23271  0.1  0.2 123496 42436 ?        Sl   07:16   0:00 hyprpaper
USERNAME   23814 16.8  0.2  39400 35780 pts/2    Ss   07:17   0:03  \_ /usr/bin/bash --posix

The Bash process on the second line of the output is another tab where ps uxf was run. Then, the only process is hyprpaper.

Second, hyprpaper is also a Wayland application similar to wl-copy. They probably lose their controlling terminal on wl_display_connect. Both programs call this function to initialize its Wayland session.

Third, hyprpaper has so-called IPC mode (which I guess stands for the interprocess communication mode?), which is enough to suspect that it launches a background worker. In fact, there seems to be a process of hyprpaper running in background in @10b14224cc’s ps uxf result.

Also, I think now I can explain why the problem comes out when ble.sh is used. ble.sh internally backs up the file descriptor of the TTY to different numbers, so even if the standard streams are closed by the background process, the backed-up descriptors remain. What is needed is to specify O_CLOEXEC to the backed-up file descriptors so that they are automatically closed in the child processes on their startup, but there is no obvious way to specify O_CLOEXEC at the shell script level.

The author of wl-copy seems to refuse to close the TTY. The author’s thought is explained in https://github.com/bugaevc/wl-clipboard/pull/110#issuecomment-785153532. That explanation contains the following phrase:

including after forking into background.

This means that wl-copy has a background process, which partly answers my question. Then, the author tries to keep stderr of the background process connected to the TTY for error logging, but it seems a bit strange to use the TTY for error logging of a background process. A background process should save its error, if any, to a log file instead of the TTY where another application might be in the foreground.

Edit: wl-copy is used by the wl-clipboard package to copy text to the system clipboard, used by things like Neovim

Ah. I see. So it’s not necessarily used as a command-line tool but can be a background worker for another program.