handlr does not forks the process so launched apps dies with parent terminal

chmln / handlr

A better xdg-utils

MIT License

616 stars 24 forks source link

handlr does not forks the process so launched apps dies with parent terminal #40

Closed freed00m closed 3 years ago

freed00m commented 3 years ago

I think this is wrong, xdg-open does fork it's launched apps so the parent terminal emulator can be closed without killing child process.

example: "I open a terminal emulator and do $ handlr open video.mkv, the mpv associated with the matroska launches and when term killed, the mpv is killed also. However when $ xdg-open video.mkv the mpv is not killed when terminal emulator dies`

It would be also awesome if this behavior could be overridden with an argument.

--nofork would behave as the current handlr behavior

nyanpasu64 commented 3 years ago

I tried and failed to reproduce this bug.

KDE, Konsole, fish shell, handlr open video.mkv, mpv doesn't close when the terminal and shell closes.
KDE, Konsole, fish shell, handlr open file.txt, Kate doesn't close when the terminal and shell closes.
KDE, Konsole, fish shell, handlr open video.mp4, VLC doesn't close when the terminal and shell closes.
KDE, xterm, bash shell, handlr open video.mkv, mpv doesn't close when the terminal and shell closes.
KDE, xterm, bash shell, handlr open video.mp4, VLC doesn't close when the terminal and shell closes.

On the other hand, not using handlr does behave as you describe:

KDE, Konsole, fish shell, mpv video.mkv blocks the terminal, and mpv closes when the terminal and shell closes.

I'm using "handlr 0.6.4" from cargo install handlr.

freed00m commented 3 years ago

@nyanpasu64 I am very sorry for not investigating further.

The behavior you describe is correct for people who are closing they terminals with a SIGTERM signal, those are people from the tiling window managers whom are use to SIGKILL the terminal window and with SIGKILL you obsere my described issue.

xdg-open does fork/doublefork more indenpendently

nyanpasu64 commented 3 years ago

I still can't reproduce your issue. This time I only tested on GNOME with kwrite:

gnome-terminal, fish shell, killall -9 fish, kwrite doesn't terminate.
gnome-terminal, fish shell, killall -9 gnome-terminal-server, kwrite doesn't terminate.
gnome-terminal, bash shell, kill -9 <BASH PID>, kwrite doesn't terminate.
gnome-terminal, bash shell, killall -9 gnome-terminal-server, kwrite doesn't terminate.
konsole, fish shell, killall -s KILL fish, kwrite doesn't terminate.
konsole, fish shell, killall -s KILL konsole, kwrite doesn't terminate.
konsole, bash shell, kill -9 <BASH PID>, kwrite doesn't terminate.
konsole, bash shell, killall -9 konsole, kwrite doesn't terminate.

(I think killall -9 and killall -s KILL are equivalent.)

What distro and DE are you on? I'm on Arch Linux, latest kernel 5.12.12-zen1-1-zen, on KDE/GNOME X11.

freed00m commented 3 years ago

Wow, that's spooky. I am using Archlinux 5.12 vanilla no zen eunning with sway started as a systemd service right after agetty drops me to zsh my shell of choice.

Also my dotfiles https://git.sr.ht/~freed00m/dotfiles/tree/master/item/.config/handlr/handlr.toml

freed00m commented 3 years ago

It is indeed not happening anymore. I am not sure what has changed since last week but it's fine now.