Re: protecting shell fds

[Paul Haahr <haahr@mv.us.adobe.com>]

Donn, thank you for writing your detailed explaination.  your example is, while  
probably rare, real, and i'm beginning to realize that i can't find a case where  
the current behavior makes more sense.  also, one key phrase in your note  
sounded the death knell for the present implementation:

> To recap my prior arguments on this, my feeling is that once the shell has
> begun reading a stream of commands, that command stream should be invulnerable
> to redirection from shell statements.

which is, of course, the crux of the argument.  what had not gotten itself into  
my thick skull until now was that ``once the shell has begun reading a stream,''
it has started reading and buffering the stream, so if input is not coming from
a tty or slow pipe writer, it has grabber more than the current es command, but  
probably the whole of the script.  therefore, the sharing that is nominally  
going on right now is with unpredictable data.

synopsis:  Donn's right, i'm wrong, es-0.7/input.c:424 is wrong, and the
	if (fd >= 3)
test in releasefds is wrong.

fixed in 0.75