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

Denys Vlasenko vda.linux at googlemail.com
Wed Nov 11 02:23:35 UTC 2009


On Wednesday 11 November 2009 00:34, Cathey, Jim wrote:
> >But everything *is* working correctly. The program sets O_NONBLOCK
> >on stdin and exits. Shell, being a stupid program, has no way
> >of knowing whether this was intended or not, is better to leave it as
> is.
> 
> Does shell also try to work with any/all odd settings
> of the stty i_flags?  I thought it just whacked them to
> what it needed and got on with life.

Try "stty -echo" from ash prompt. It will respect the setting.

> >Now (after 1.10.x) it is using nonblock_safe_read()
> >instead of just safe_read(), and thus does not need
> >to switch off O_NONBLOCK.
> 
> Clever, but was it a good idea?  That just exported
> the problem to _every_ potential child process of a
> shell.

Try to run this z.sh via "ash z.sh":

z.sh
====
set_O_NONBLOCK_on_stdin_and_exit
echo Please edit a file
vi a_file.txt

This wasn't working even before the introduction
of nonblock_safe_read() - shell wasn't "fixing" stdin
in this case, and thus vi got O_NONBLOCKed.


> >>alternative would be to fix nearly all apps that use stdin (cat, vi,
> etc)!
> 
> Fix?  Mangle!  This is the wrong way to go.

Why you call the same thing (resetting of O_NONBLOCK)
in sh "a fix" and in vi "mangle"??

> >There are two ways: (a) detect and switch off O_NONBLOCK
> >as shown above, or (b) use code which works correctly
> >even on O_NONBLOCKed fd:
> 
> Not sure this (b) is a good idea.

Works like a charm though.

> >Or to bug kernel folks to finally do something about broken API.
> >They might provide a way to do nonblocking reads without
> >setting troublesome O_NONBLOCK bit. Then applications
> >can slowly migrate to this non-buggy API.
> 
> At times like these I sure miss the nice async I/O of DNIX.
> O_NONBLOCK had nothing to do with what reads did, it was
> the old-school blocking open flag only.  AIO was conducted
> via special read/write calls, the 'asynchritude' was tied
> to the specific I/O request and nothing to do with the file
> descriptor.

Exactly. That how it should be done.

Did anyone send an email about it to lkml already?
--
vda


More information about the busybox mailing list