Launching a program via `xdg-open` from a subshell without blocking

Question

I've noticed that calling xdg-open from a subshell will reliably block until the launched process is closed. I suspect there may be a reason for this, but I'm not sure as to why. For example, launching Nautilus doesn't block when calling xdg-open directly from the command line:

xdg-open ~/dir ; echo foo              # doesn't block

but invoking xdg-open from a subshell will reliably block the terminal

var=$(xdg-open ~/dir ; echo foo)       # blocks

{ xdg-open ~/dir ; echo foo ; } | cat  # blocks.

My understanding is that xdg-open detaches the launched process from the shell session so that it's no longer a subprocess. I'd therefore expect this to be different to e.g. invoking sleep 1 & in a subshell for which it seems reasonable that the terminating subshell will block until all subprocess have completed, i.e.

var=$(sleep 1 & echo foo)      # also blocks, but understandable.

But if xdg-open is detaching the process, what's causing the subshell to wait?

In what may (?) be a partial answer, I've noticed that running

{ xdg-open <file> ; ps ; } | cat

shows that depending on program launched by <file>, those that block are also the ones that keep the tty as their controlling terminal. That begs the question why this happens, why this happens only in a subshell and ultimately what's a good way to a launch desktop process from the terminal that will fully and reliably detach from it?

Edit: fix syntax on bash.

Answer 1

First of all, in your examples,

var=$(sleep 1 & ; echo foo)

should not work in bash, because & already serves as a line end.
(-bash: command substitution: line 1: syntax error near unexpected token `;')

Try

var=$(sleep 1 & echo foo) # no ';' !!

(echo $var: foo)

In my understanding, a simple

xdg-open <something> & # optional: echo foo

should do the trick, either in a sub-shell or outside.