Simulate empty STDIN to detached command

Question

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

Answer 1

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

Answer 2

You need to use the command disown. This will release the STDIN/STDOUT from the current shell where you're running these commands.

% disown -a

-or-

% sleep 100 &
[1] 7987
% disown %1

See the bash man page for further details.

disown [-ar] [-h] [jobspec ...] Without options, each jobspec is removed from the table of active jobs. If the -h option is given, each jobspec is not removed from the table, but is marked so that SIGHUP is not sent to the job if the shell receives a SIGHUP. If no jobspec is present, and neither the -a nor the -r option is supplied, the current job is used. If no jobspec is supplied, the -a option means to remove or mark all jobs; the -r option without a jobspec argument restricts operation to running jobs. The return value is 0 unless a jobspec does not specify a valid job.

Answer 3

I needed something like this for running expect scripts from an automated test system (Jenkins). Expect automatically closes stdout when it detects EOF on stdin, and that causes all writes to stdout to fail and terminate the test. I worked around it by simply making its stdin /dev/zero.

mycommand </dev/zero