Simulate empty STDIN to detached command

nohupstdin

i want to detach command either with 'command &' in the end, or with 'nohup command &', but it stops right after detaching it.

command is little specific, if it receives eof on input, it breaks so /dev/null as input will lead to end and solution that usualy works: 

$ command < /dev/null > /dev/null 2>&1 &

not working…

is there other device in unix/linux, that can replace /dev/null and behave like empty input, but not sending eof.

(by the way, command is very useful multicasting tool emcast, I can try patching it my self, or find patched version for this purpose… but it seems that problem can be solved outside)

I'm adding this EDIT to make my question more clear. I made this C program of 2 lines that works perfectly: program name is "donothing"

#include <unistd.h>
int main() {  while (1)  { sleep(10); } return 0; }

and it is what I am looking for, some device/program, that doing nothing, but leave its stdout open. Both ("command & … disown" and "nohup command &") works.

$ donothing | mycommand >/dev/null & 
$ disown %1

works well, so now question is only: what unix device/program behaves like my 'donothing'.

Best Answer

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).

Related Question