async commands (&) run via `-c` aren't spawned before brush exits

[ArtikusHG]

brush version

sh -c -- fix debug build

bash version (for comparison)

5.3.0

Platform / OS

Linux

Steps to reproduce

brush -c "some-command &" - does not run at all

Actual behavior (brush)

When trying to run a command with -c that has an & symbol at the end, the command doesn't run. If there's another command after it, it does run, but the commands run in a seemingly random order, sometimes some of them don't run at all.

[~] sh -c "echo 1"
1
[~] sh -c "echo 1 &" # no output :(
[~] sh -c "echo 1 & echo 2 & echo 3 & echo 4"
1
2
3
4
[~] sh -c "echo 1 & echo 2 & echo 3 & echo 4"
4
[~] sh -c "echo 1 & echo 2 & echo 3 & echo 4"
4
1
2
[~] sh -c "echo 1 & echo 2 & echo 3 & echo 4"
1
4
[~] sh -c "echo 1 & echo 2 & echo 3 & echo 4"
4
2
1
[~] sh -c "echo 1 & echo 2 & echo 3 & echo 4"
4
1
2

Note that in an interactive shell both running a single command and multiple commands works fine.

From my understanding, the fact that they're in random order is expected, but the fact that sometimes only some of them run isn't great, and the fact that if I try to run a single command in the background, it simply ignores that request, prevents me from being able to use a lockscreen using swayidle.

Expected behavior

commands with & run correctly, just like in interactive shell

Additional context

Sorry for the load of bug reports :/ I'm probably the only one crazy enough to try to use this as their system shell lol

[reubeno]

No apologies needed, keep the reports coming!

Any chance you could try in your setup asynchronously running commands having some other side effect we could observe (e.g., touch some-file)? I'm trying to sort out if it's a problem with the commands not executing, or a problem with the commands' standard output getting lost (but the commands are still running).

[ArtikusHG]

The commands definitely aren't running - as I said, I noticed this because my screen locker stopped working. It basically looks like this (simplified):

swayidle timeout 30 "hyprlock &" timeout 60 "systemctl suspend"

This command will wait for 30 seconds of inactivity, and then run "hyprlock &". It works fine without the &, and does nothing at all when there is an &. I cannot use this without detaching the process, because if I don't, the next command in the next timeout doesn't run - so after 30 seconds my screen gets locked, but the laptop doesn't get suspended a minute later and just keeps disaying the lockscreen forever.

[oech3]

This happens without -c:

$ bash -- # success
$ brush --
error: failed to source file: --

[ArtikusHG]

@oech3 I think that's a separate issue? might still be related tho

[reubeno]

Agreed -- those are unrelated. (@oech3 -- if you see an issue with -- parsing on the command line, then we should track that separately.)

I looked more into the original issue described here -- it's not a parsing problem. It's that the background commands are queued to async tasks that are getting terminated on shell exit, even before they've spawned the commands in question (e.g., touch, hyprlock).

We've got some work to do in order to resolve this, but if you're looking for a workaround, @ArtikusHG, then I believe it will be sufficient to do something like:

swayidle timeout 30 "hyprlock & sleep 1" timeout 60 "systemctl suspend"

Definitely not a proper solution, but the synchronous sleep tacked on the end gives the shell time to ensure that the async tasks have run. Here was how I reproduced this with async sleep commands:

You'll note they don't show up in ps at all in the initial run. In the second run, the synchronous sleep 0.5 was sufficient on my box to let all of them spawn -- and you can see them in the ps output afterwards.

In all, another really good bug, @ArtikusHG. I hope this doesn't discourage you too much from our project 😄. We'll use this issue to track the overall problem described here.

[ArtikusHG]

@reubeno I may be missing something but this PR doesn't fix the issue? This is me trying the latest build from the PR's artifact - still nothing:

[reubeno]

Shoot -- I didn't mean to close the issue, just to reference it. It added tests that reproduce the issue (and they do, in fact, fail).

Apologies for the confusion. I'll reopen.