I have a script named d in my PATH and it contains this:
("$@" > /dev/null 2>&1 &)
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>.
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.
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 &.
() 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.
I have a script named
din my PATH and it contains this:("$@" > /dev/null 2>&1 &)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>.Shouldn’t you end with
& disownto fully detach?IIRC
disownis a shell built-in command, so its use is a bit limited. Not sure if&is also a built-in, but I founddisownto not work in some situations. Besides, it’s shorter.After looking into it a bit more, its at least a builtin for
bashbut is otherwise not POSIX. I guessnohup ... &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 bewait()ed on, if only using&.good idea, I’ve been manually typing out variations of this as needed for years.
How does this even work? I get the redirection part, but how is the command executed in a detached state?
()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 thannohup,disown, and it’s a lot shorter than most other solutions.the last & is like doing “command &”. d is a function that takes argument and $@ is usually the first argument