Subject: bug#20214: Nohup input redirection inconsistent with documentation

From: Isaac Schwabacher <[email-masked]>
Date: Fri, 27 Mar 2015 14:51:37 -0500

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