16:33 <cbb> jmcantrell: I'm curious how you were running that script you mentioned yesterday

16:34 <cbb> were you starting it from a shell or with something like `foot ./script.bash`?

16:35 <cbb> by "from a shell" I mean an interactive shell in foot

16:42 <cbb> I think running "backgrounded" GUI apps from an interactive shell is perfectly reasonable tbh and there's a way to do it properly

20:05 <jmcantrell> cbb: my testing was done using `foot ./script` in an interactive shell (in foot), but i intended it to be run from a bindsym in sway. i found out that it behaves the same way running it in another terminal, like alacritty, so i'm not sure it's indicative of anything wrong with foot

20:07 <cbb> jmcantrell: oh ok, I don't get why you'd run `foot ./script` instead of just `./script` then

20:11 <cbb> if you want to run a GUI app from an interactive shell, you can "background" it with e.g. `setsid --fork seahorse >/dev/null 2>&1`

20:23 <jmcantrell> does that work for non-interactive too? i'm curious why this is necessary. seems like backgrounding + disowning is the correct (?) way

20:26 <cbb> jmcantrell: it's not necessary for non-interactive, but it should work nontheless

20:26 <cbb> so you can do it unconditionally in a script like that, if you want it to work in either context

20:33 <cbb> using setsid(1) just eliminates all the quirks around controlling terminals and process groups (and the foreground group getting SIGHUP when losing the tty)

20:49 <jmcantrell> cbb: thanks. i was not aware of setsid

21:00 <cbb> jmcantrell: no worries

21:01 <cbb> I should note that setsid(1) comes from util-linux, so it's not portable to BSDs if that matters

21:04 <jmcantrell> understood