O_NONBLOCK on stdin left set by child (using ash shell)

[Johns Daniel]

On Tue, Nov 10, 2009 at 10:50 PM, Mike Frysinger <vapier at gentoo.org> wrote:
> On Tuesday 10 November 2009 17:50:23 Jason Curl wrote:
>> I did some rummaging on the opengroup, and I found this:
>> http://opengroup.org/onlinepubs/7990989799/xcu/sh.html
>>
>> "If the standard input to /sh/ is a FIFO or terminal device and is set
>> to non-blocking reads, then /sh/ will enable blocking reads on standard
>> input. This will remain in effect when the command completes. (This
>> concerns an instance of /sh/ that has been invoked, probably by a
>> C-language program, with standard input that has been opened using the
>> O_NONBLOCK flag; see /open()
>> <http://opengroup.org/onlinepubs/7990989799/xsh/open.html>/ in the *XSH*
>> specification. If the shell did not reset this flag, it would
>> immediately terminate because no input data would be available yet and
>> that would be considered the same as end-of-file.)"
>>
>> Does this then imply that we really should be turning off O_NONBLOCK?
>
> this wording applies only to the initial start up of a shell, not to the
> continued execution of other commands.
>
> i.e. when you run `sh`, that shell will check stdin and reset to blocking
> reads if need be.  it does not apply to a shell that runs `foo` and thus has
> the non blocking bit changed in mid execution.

What does it say about the state of the shell when a new command is started?

I don't know; I am asking to find out. All I know is that no Linux
shell I know of, except the current BusyBox shells, have this
behavior. Even the old BusyBox shells had "standard" behavior.

Try this program on bash and in BusyBox ash:

#include <unistd.h>
#include <fcntl.h>
int main()
{
        fcntl(0, F_SETFL, fcntl(0, F_GETFL) | O_NONBLOCK);
        return 0;
}

Works fine in bash. In BusyBox ash, the shells exits when I press the
up arrow (for command history) after running this program! I don't
think you can convince me that this is correct behavior!

> -mike