bug#20214: Nohup input redirection inconsistent with documentation
tags 20214 fixed close 20214 stop (triaging old bugs0 On Fri, Mar 27, 2015 at 3:11 PM, Paul Eggert wrote: Isaac Schwabacher wrote: This is confusing at best Yes, at the very least the documentation should be improved. I installed the attached patch to try to do that. On 29/03/15 10:07 AM, Jim Meyering wrote: Thinking about this some more, I conclude that history, and the ability to expose a few misuses are perhaps not sufficient argument for maintaining the status quo. So if you (Paul) want to flip nohup to universal acceptor, I would not object. With nohup's documentation improved, and no further comments/changes in 3 years, I'm closing this as "fixed". -assaf
bug#20214: Nohup input redirection inconsistent with documentation
On Fri, Mar 27, 2015 at 7:14 PM, Jim Meyering j...@meyering.net wrote: On Fri, Mar 27, 2015 at 3:11 PM, Paul Eggert egg...@cs.ucla.edu wrote: Isaac Schwabacher wrote: This is confusing at best Yes, at the very least the documentation should be improved. I installed the attached patch to try to do that. Is it really better for a read on stdin to fail with EBADF rather than simply returning EOF It depends on whether we want GNU nohup to be a universal donor or a universal acceptor. Right now it's more the former (if a program works with GNU nohup it should be portable to other nohup platforms); a nohup that makes stdin read from /dev/null would be more accepting of badly-written code developed elsewhere. I suppose I could be talked into that, particularly given Matlab's misbehavior here. Jim? My rationale (didn't check and assume it was I) was that it is better to fail in a way more likely to alert the incautious user that they have misused the tool, rather than to silently accept questionable usage. Considering it has been this way for 10 years, and has exposed real bugs in client code, I am inclined to prefer the existing behavior. Don't shoot the messenger? Thinking about this some more, I conclude that history, and the ability to expose a few misuses are perhaps not sufficient argument for maintaining the status quo. So if you (Paul) want to flip nohup to universal acceptor, I would not object.
bug#20214: Nohup input redirection inconsistent with documentation
On 15-03-27, Jim Meyering wrote: On Fri, Mar 27, 2015 at 3:11 PM, Paul Eggert egg...@cs.ucla.edu wrote: Isaac Schwabacher wrote: This is confusing at best Yes, at the very least the documentation should be improved. I installed the attached patch to try to do that. Is it really better for a read on stdin to fail with EBADF rather than simply returning EOF It depends on whether we want GNU nohup to be a universal donor or a universal acceptor. Right now it's more the former (if a program works with GNU nohup it should be portable to other nohup platforms); a nohup that makes stdin read from /dev/null would be more accepting of badly-written code developed elsewhere. I suppose I could be talked into that, particularly given Matlab's misbehavior here. Jim? My rationale (didn't check and assume it was I) was that it is better to fail in a way more likely to alert the incautious user that they have misused the tool, rather than to silently accept questionable usage. Considering it has been this way for 10 years, and has exposed real bugs in client code, I am inclined to prefer the existing behavior. Fair enough. Don't shoot the messenger? You mean the MATLAB rep who informed me that I could work around the land mine by not stepping on it? :P
bug#20214: Nohup input redirection inconsistent with documentation
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
bug#20214: Nohup input redirection inconsistent with documentation
Isaac Schwabacher wrote: 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. Herp derp, I completely forgot that read(2) and write(2) aren't symmetric. Of course you can't get SIGPIPE from a read. ...instead you get EOF.
bug#20214: Nohup input redirection inconsistent with documentation
Isaac Schwabacher wrote:
This is confusing at best
Yes, at the very least the documentation should be improved. I installed the
attached patch to try to do that.
Is it really better for a read on stdin to fail with EBADF rather than simply
returning EOF
It depends on whether we want GNU nohup to be a universal donor or a universal
acceptor. Right now it's more the former (if a program works with GNU nohup it
should be portable to other nohup platforms); a nohup that makes stdin read from
/dev/null would be more accepting of badly-written code developed elsewhere.
I suppose I could be talked into that, particularly given Matlab's misbehavior
here. Jim?
From 666dec6b34e1204b173672f9bad47f34cd8bad3f Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Fri, 27 Mar 2015 15:01:35 -0700
Subject: [PATCH] nohup: clarify stdin redirection
Problem reported by Isaac Schwabacher in:
http://bugs.gnu.org/20214
* doc/coreutils.texi (nohup invocation): Clarify that when nohup's
stdin gets redirected, it's unreadable.
* doc/coreutils.texi (nohup invocation):
* src/nohup.c (usage): Don't promise /dev/null.
---
doc/coreutils.texi | 13 +++--
src/nohup.c| 2 +-
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 6110cec..3cbce63 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -16714,12 +16714,13 @@ out. Synopsis:
nohup @var{command} [@var{arg}]@dots{}
@end example
-If standard input is a terminal, it is redirected from
-@file{/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 @samp{nohup @var{command} [@var{arg}]@dots{} /dev/null}
-instead.
+If standard input is a terminal, redirect it so that terminal sessions
+do not mistakenly consider the terminal to be used by the command.
+Make the substitute file descriptor unreadable, so that commands that
+mistakenly attempt to read from standard input can report an error.
+This redirection is a GNU extension; programs intended to be portable
+to non-GNU hosts can use @samp{nohup @var{command} [@var{arg}]@dots{}
+0/dev/null} instead.
@flindex nohup.out
If standard output is a terminal, the command's standard output is appended
diff --git a/src/nohup.c b/src/nohup.c
index 9bc8686..8cdaced 100644
--- a/src/nohup.c
+++ b/src/nohup.c
@@ -63,7 +63,7 @@ Run COMMAND, ignoring hangup signals.\n\
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
printf (_(\n\
-If standard input is a terminal, redirect it from /dev/null.\n\
+If standard input is a terminal, redirect it from an unreadable file.\n\
If standard output is a terminal, append output to 'nohup.out' if possible,\n\
'$HOME/nohup.out' otherwise.\n\
If standard error is a terminal, redirect it to standard output.\n\
--
2.1.0
bug#20214: Nohup input redirection inconsistent with documentation
On Fri, Mar 27, 2015 at 3:11 PM, Paul Eggert egg...@cs.ucla.edu wrote: Isaac Schwabacher wrote: This is confusing at best Yes, at the very least the documentation should be improved. I installed the attached patch to try to do that. Is it really better for a read on stdin to fail with EBADF rather than simply returning EOF It depends on whether we want GNU nohup to be a universal donor or a universal acceptor. Right now it's more the former (if a program works with GNU nohup it should be portable to other nohup platforms); a nohup that makes stdin read from /dev/null would be more accepting of badly-written code developed elsewhere. I suppose I could be talked into that, particularly given Matlab's misbehavior here. Jim? My rationale (didn't check and assume it was I) was that it is better to fail in a way more likely to alert the incautious user that they have misused the tool, rather than to silently accept questionable usage. Considering it has been this way for 10 years, and has exposed real bugs in client code, I am inclined to prefer the existing behavior. Don't shoot the messenger?
