`bg { command }` fails to persist detached process

[joshahussey]

Describe the bug:
The script following script fails to run the command but exits 0, although removing bg the command runs fine.

#!/usr/bin/env murex bg { command }

Expected behaviour:
Command runs in a background process and the script executes successfully.

Platform (please complete the following information):

• OS: Linux josh-n-home 6.7.5 Refractoring #1-NixOS SMP PREEMPT_DYNAMIC Fri Feb 16 18:14:32 UTC 2024 x86_64 GNU/Linux
• Terminal Emulator: Ghostty
• Murex version: 6.0.1000

Additional context
Attempting to start waybar as a background process, although it seems that no background processes are working.

[lmorg]

hi @joshahussey

I think the issue here isn't that the process isn't running in the background but rather the commands you're running are builtins, which are threads rather than processes (for performance reasons). So while they're running in the background, they'll end when Murex ends. And since the only command is bg, you've got nothing to wait for them to finish.

I suspect you'll need to run Murex in the background.

Can you share your script please?

Thinking out loud: I wonder if there is an opportunity for a daemonise-type command here 🤔

[joshahussey]

I am using it as an "exec-once=/path/to/script" in my hyprland config so the script is quite small.

The lines I posted above are the entirety of the script as it is only intended to start waybar.

`#!/usr/bin/murex

bg { waybar }`

A couple of things to note:
The script does not start waybar regardless if it is called manually or through the hyprland config.

I have made a nixpkgs fork and changed the murex package to latest and also added the shellPath passthru so that it can be used as a default shell (which I am doing).
Although the script does not run even with bash as a default shell and starting a murex shell manually.

I agree with that assessment, perhaps some type of daemonise style command may be useful to distinguish between processes and threads. The process exits 0 so I have a hunch that as you said, the thread ends as the main process exits.

I will see if running bg { waybar } directly from the shell works, but my bet is your diagnoses is definitely the cause.

[lmorg]

ahhh yes. I can see the issue. The script finishes before bg finishes forking waybar. eg

» murex -c "bg { sleep 999 }"
» ps aux | grep sleep
Error in `grep` (0,10): exit status 1

I don't have waybar installed but I can emulate it with sleep 999, as seen above.

If I put a sleep in after bg, that gives bg long enough for fork. eg

» murex -c "bg { sleep 999 }; sleep 1"
» ps aux | grep sleep
lmorg   58501   0.0  0.0 408495776   1136 s004  S+    7:01pm   0:00.00 sleep 999

This is obviously not a great solution long term so I'll work on a fix.

---

As an aside fixing this might not be trivial because bg should be non-blocking. That's the entire point of it. It wouldn't be very successful at running things in the background if it were. But equally what we need here is for it to block until at least the first process has been started. So there needs to be some logic to check for a PID before releasing control.

[lmorg]

@joshahussey An update on this:
I've spent the last couple of months prototyping different behaviours but the problem is having consistent behaviour between external executables (like waybar) vs builtins and functions (eg regexp) and across platforms too (specifically Windows vs POSIX platforms, such as Linux and MacOS).

I think the only way to solve this in a predictable way is to add a flag --detach (or -d for short) which forks the entire process and runs that in the background.

I'll start work on that in the next few days