For your command to detect eof, it has to read from stdin. So presumably it is expecting some input. So it sounds like what you need is not an empty input (/dev/null is exactly meant for that), but input that never comes.
It can be simulated with a pipe where nobody is ever going to write on the other end like:
sleep 999999999 | the-command
Or to avoid having to run that extra sleep command, it could be done with a named pipe:
fifo=$(mktemp -u) &&
mkfifo "$fifo" &&
(rm "$fifo" && the-command <&3 3<&- &) 3<> "$fifo"
Here using an intermediary file descriptor to work around the fact that the shell connects stdin to /dev/null implicitely when you start a command with & (unless you add an explicit stdin redirection like our <&3 here).
On Linux (and probably on Linux only), you can also do:
the-command < /dev/fd/1 3>&1 > /dev/null | :
/dev/fd/1 where fd 1 is connected to a pipe, on Linux, behaves like a named pipe. That is, when you open it in read mode, you get the reading end of the pipe.
So above, fd 0 will be connected to the reading end of a pipe whose other end is on the fd 3 of the-command. Because the-command is not going to write anything on its fd 3, any read attempt on fd 0 will block (or a non-blocking read will return with there's nothing to read yet, or a select/poll will return nothing to read either as the-command is probably doing if it's doing anything else than waiting for input that never comes).
Best Answer
First of all, every time you execute a command, you shell will fork a new process, regardless of whether you run it with
&or not.&only means you're running it in the background.Note this is not very accurate. Some commands, like
cdare shell functions and will usually not fork a new process.type cmdwill usually tell you whethercmdis an external command or a shell function.type typetells you thattypeitself is a shell function.nohupis something different. It tells the new process to ignoreSIGHUP. It is the signal sent by the kernel when the parent shell is closed.To answer your question do the following:
emacs &(by default should run in a separate X window).exit.You'll notice that the
emacswindow is killed, despite running in the background. This is the default behavior andnohupis used precisely to modify that.Running a job in the background (with
&orbg, I bet other shells have other syntaxes as well) is a shell feature, stemming from the ability of modern systems to multitask. Instead of forking a new shell instance for every program you want to launch, modern shells (bash,zsh,ksh, ...) will have the ability to manage a list of programs (or jobs). Only one of them at a time can be at the foreground, meaning it gets the shell focus. I wish someone could expand more on the differences between a process running in the foreground and one in the background (the main one being acess tostdin/stdout).In any case, this does not affect the way the child process reacts to
SIGHUP.nohupdoes.