Re: is this my mistake or someone elses?

["Jeffrey C. Rogers" <rogerj@mailhost.ctron.com>]

> I think the problem is that you should need to do a
> 	fd = fdmap(fd);
> after you've got the fd you want and before you actually use it for any
> I/O operations.  This is part of the deferred fd mapping system which is
> used to allow redirections, etc, to run in the context of a parent shell
> and not require forking for builtins with redirections.

Ok, that gets my read to work with arbitrary descriptors properly.  Now more 
questions about file descriptors:

 - Is there any way to make open descriptors hang around and remain open 
between commands, or permanently (until otherwise affected) with exec?
For example, this is in rc:
; touch food
; cat food
; exec <[4] food
; cat <[0=4]
; cat >> food
pizza 
taco
; cat <[0=4]
pizza
taco
; cat <[0=4]
; cat >> food
burger king
mcdonalds
; cat <[0=4]
burger king
mcdonalds
; cat <[0=4]
; exec <[4=]
; cat <[0=4]
dup2: Bad file number
; 

fd 4 remains open (and with the same file pointer, as you would expect - that 
could be a neat way to check your mail) in between commands, and only gets the 
dup error after fd4 is explicitly closed. But in es:

; exec <[4] food
; cat <[0=4]
dup: Bad file number
; 

It would seem that the fds get closed in between commands. For a much more 
common/useful example, in a shell script:
exec >[1] /dev/null >[2] /dev/null
.
.
exec >[1=0] >[2=0]

to temporarily disable all output. But it doesn't work.

 - should writing to a closed file descriptor really be a fatal error?

; echo >[1=]
write: Bad file number
<shell exits>

And you can't even unwind-protect it, because it just exits (line 288, print.c)

 - why can't %parse read from somewhere other than the terminal? 

; fork {echo <={%parse <etest}}
input.c:210: assertion failed (in->fd >= 0)
abort--core dumped
; 

Without the fork it just reads from the terminal (I assume because of the 
deferred fd system).  This probably isn't much of an issue, as there's not too 
many places where it would be used (implementing . in the shell comes to 
mind), but when it's supposed to be extensible, why a restriction like this? 

Are the assertions over-protective (some seem to be - in gcndup, for example), 
or are they generally just killing you before you would be otherwise?

> Nice hack.  Tell me how you like working with your read primitive, once
> you get past this bug I threw in your way.

Thanx.  I'll post my es version of ash (adventure shell) once I finish it ;-)

One note about my read prim - the buffered reading (using the readctl prim) 
doesn't work _quite_ right. (correct behavior can be reverted to by setting 
the bufsiz to 0, which doesn't use any nested pointers or anything).  Anyone 
care to debug it?

Diversion