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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
