bug#20214: Nohup input redirection inconsistent with documentation

[Isaac Schwabacher]

The GNU nohup manual currently has the following passage:

> If standard input is a terminal, it is redirected from
> /dev/null so that terminal sessions do not mistakenly consider
> the terminal to be used by the command. This is a GNU
> extension; programs intended to be portable to non-GNU hosts
> should use `nohup command [arg]... </dev/null' instead.

This is confusing at best, as the actual behavior of GNU nohup, as noted in the 
source at
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/nohup.c;h=9bc868604b66c573e28289e096f601aded942395;hb=master#l120
 ,
is to open /dev/null for *writing*, so that attempts to read from stdin fail 
with EBADF. Calling this redirection "from" /dev/null is a stretch. If this 
behavior is to remain, the documentation should clearly state this fact, and 
make clear that reading from stdin will fail with EBADF rather than returning 
EOF as currently implied. It is especially problematic that the suggested 
portable alternative behaves differently in this respect.

However, I am not convinced that the current behavior is optimal. To begin 
with, it is exactly as consistent with POSIX as it is with its own 
documentation:

> If standard input is associated with a terminal, the nohup utility may 
> redirect standard input from an unspecified file.

The discussions on this list which appear to have led POSIX to this point 
discuss many alternative behaviors, but there's only one unfavorable mention of 
the possibility of having GNU nohup do as its manual says it does
( http://lists.gnu.org/archive/html/bug-coreutils/2005-05/msg00199.html ),
and no counterargument is presented. Is it really better for a read on stdin to 
fail with EBADF rather than simply returning EOF ("nothing to see here, move 
along")? The most spectacular failure I have seen in response to this behavior 
is MATLAB, which responds to read errors on stdin by executing a 
denial-of-service attack on the filesystem(!). (The nature of nohup makes this 
failure mode particularly problematic, as the likelihood is rather high of it 
occurring on a Friday night after the perpetrator has left the building.) While 
I would not dream of blaming GNU for MATLAB's braindeadness, the fact remains 
that EOF on stdin is an expected input that follows well-tested code paths 
leading to an orderly exit from an application, while EBADF on stdin is much 
more likely to head into code that was written with an attitude of "I suppose I 
should handle this, just in case" and never tested. Even GNU clisp is not 
exempt:
http://lists.gnu.org/archive/html/bug-coreutils/2009-06/msg00140.html .

If the maintainers determine that this argument is still not enough to outweigh 
the benefits of reads from stdin failing with an error, perhaps it would be 
sufficient to redirect stdin from a closed fifo instead, so that applications 
that do not explicitly promise to handle EPIPE would be killed by SIGPIPE.

ijs