>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. >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. >>alternative would be to fix nearly all apps that use stdin (cat, vi, etc)! Fix? Mangle! This is the wrong way to go. >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. >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. Made mixing and matching I/O styles seamless. You could also use VMIN/VTIME to poll ttys, if you wanted to, but that was strictly a non-native compatibility tool. (Just as Berkeley sockets were on that platform.) The native servers used only AIO, programs were pretty simple and bug-free as a result. (Unless you couldn't grok state machines, in which case your crap never worked at all.) -- Jim _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
