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

[Mike Frysinger]

On Wednesday 11 November 2009 10:09:48 Johns Daniel wrote:
> On Tue, Nov 10, 2009 at 10:50 PM, Mike Frysinger 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 dont think it does say which means the behavior cannot be relied upon.  this 
would be a question to post to the austin group mailing list and/or mantis bug 
tracker to ask for clarification.

> 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.

quoting standard there is correct ... there doesnt appear to be an actual 
standard currently, only what other shells seem to be doing

> 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!

technically speaking, without posix making an explicit statement, any behavior 
here is correct ;p

i dont personally care one way or the other wrt nonblocking, so dont take my 
comments to mean i'm in favor of specific behavior.  i do care about termios 
settings, but we arent talking about those here ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20091111/3c05bcc0/attachment.pgp>