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

Previous Next

Full log

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.

Previous Next

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