> This is by design and part of how multi-tool script programming works.
The Unix design is that scions (via fork() and execve()) inherit stuff from their ancestors. If I'm running "nice shoes" and the "nice" program sets stdin non-blocking, then the "shoes" program, which is just execve'd from "nice", will have to deal with a nonblocking stdin. That's perfectly normal. However, what is *not* normal and an aberration in the Unix file handling specification, is that a child can change the parent's environment. That is what happens in a shell; that is what Denys is talking about. #!/bin/sh ( head -n 1 ; cat ) < /nfs/file If "head" sets stdin nonblocking, then every process that shares it, *including its parent* the shell, sees it as nonblocking. The nonblocking state goes *back up* the process tree. And then, the "cat" process inherits it, and if /nfs/file is on a slow network... you lose. > Ordinary file IO never blocks. Show me ordinary file IO, and I'll show you a violation of the Unix genericity principle. My stdin might be the network, or a pipe, or a device, and I shouldn't have to care. > There's no sense in introducing more hideous non-portable > Linux-specific ways to do things that can already be achieved. The only portable workaround to the problem at hand is patching every shell to sanitize all file descriptor flags before forkexecing every command, and it only helps shell programs. The right way to fix this is to have the Unix specification changed; and since the Unix specification is a huge joke that only officializes existing behaviour as standard (if you don't believe me, check http://pubs.opengroup.org/onlinepubs/9699919799/functions/gets.html - it's still in the standard, in friggin August 2011), the best way to have it change is to push Unix implementors towards the change. Denys is right, the Linux kernel is the place to start lobbying. -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
