GNU bug report logs - #20214
Nohup input redirection inconsistent with documentation

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20214 in the body.
You can then email your comments to 20214 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Isaac Schwabacher <ischwabacher <at> wisc.edu>
To: bug-coreutils <at> gnu.org
Subject: Nohup input redirection inconsistent with documentation
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

Message #8 received at 20214 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Isaac Schwabacher <ischwabacher <at> wisc.edu>, 20214 <at> debbugs.gnu.org
Subject: Re: bug#20214: Nohup input redirection inconsistent with documentation
Date: Fri, 27 Mar 2015 15:11:39 -0700

[Message part 1 (text/plain, inline)]

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?

[0001-nohup-clarify-stdin-redirection.patch (text/x-patch, attachment)]

Message #11 received at 20214 <at> debbugs.gnu.org (full text, mbox):

From: Isaac Schwabacher <ischwabacher <at> wisc.edu>
To: 20214 <at> debbugs.gnu.org
Subject: Re: bug#20214: Nohup input redirection inconsistent with documentation
Date: Fri, 27 Mar 2015 17:31:28 -0500

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.

Message #14 received at 20214 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 20214 <at> debbugs.gnu.org, Isaac Schwabacher <ischwabacher <at> wisc.edu>
Subject: Re: bug#20214: Nohup input redirection inconsistent with documentation
Date: Fri, 27 Mar 2015 19:14:13 -0700

On Fri, Mar 27, 2015 at 3:11 PM, Paul Eggert <eggert <at> 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?

Message #17 received at 20214 <at> debbugs.gnu.org (full text, mbox):

From: Isaac Schwabacher <ischwabacher <at> wisc.edu>
To: Jim Meyering <jim <at> meyering.net>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 20214 <at> debbugs.gnu.org
Subject: Re: bug#20214: Nohup input redirection inconsistent with documentation
Date: Sat, 28 Mar 2015 12:34:10 -0500

On 15-03-27, Jim Meyering  wrote:
> On Fri, Mar 27, 2015 at 3:11 PM, Paul Eggert <eggert <at> 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

Message #20 received at 20214 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 20214 <at> debbugs.gnu.org, Isaac Schwabacher <ischwabacher <at> wisc.edu>
Subject: Re: bug#20214: Nohup input redirection inconsistent with documentation
Date: Sun, 29 Mar 2015 09:07:13 -0700

On Fri, Mar 27, 2015 at 7:14 PM, Jim Meyering <jim <at> meyering.net> wrote:
> On Fri, Mar 27, 2015 at 3:11 PM, Paul Eggert <eggert <at> 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.

Message #23 received at 20214 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 20214 <at> debbugs.gnu.org
Subject: Re: bug#20214: Nohup input redirection inconsistent with documentation
Date: Mon, 22 Oct 2018 20:06:26 -0600

tags 20214 fixed
close 20214
stop

(triaging old bugs0

>> On Fri, Mar 27, 2015 at 3:11 PM, Paul Eggert <eggert <at> 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.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.