[PATCH] ash: clear NONBLOCK flag from stdin when in foreground

[Laurent Bercot]

> 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