It allows me to run any program in a fully detached state in a way that works even if the terminal that started the program closes, and it's as simple as d <command>.

[–] stewie410@programming.dev 4 points 2 days ago (1 children)

Shouldn't you end with & disown to fully detach?

[–] Object@sh.itjust.works 2 points 2 days ago* (last edited 2 days ago) (1 children)

IIRC disown is a shell built-in command, so its use is a bit limited. Not sure if & is also a built-in, but I found disown to not work in some situations. Besides, it's shorter.

[–] stewie410@programming.dev 1 points 2 days ago

shell built-in command

After looking into it a bit more, its at least a builtin for bash but is otherwise not POSIX. I guess nohup ... & would be the POSIX compliant equivalent, though still not a builtin.

Its my understanding that & backgrounds, not necessarily detaches, a process -- if the parent process closes, I think the background tasks would still be wait()ed on, if only using &.

[–] Redjard@lemmy.dbzer0.com 7 points 3 days ago

good idea, I've been manually typing out variations of this as needed for years.

[–] Gobbel2000@programming.dev 2 points 2 days ago (2 children)

How does this even work? I get the redirection part, but how is the command executed in a detached state?

[–] Object@sh.itjust.works 3 points 2 days ago

() creates a subshell, and & runs the command in background. The $@ means everything after the first argument, so the <command> is executed like a normal command. I am not sure why this works, but it has worked more consistently than nohup, disown, and it's a lot shorter than most other solutions.

[–] MadhuGururajan@programming.dev 1 points 2 days ago* (last edited 2 days ago)

the last & is like doing "command &". d is a function that takes argument and $@ is usually the first argument