Re: is this my mistake or someone elses?

[haahr@netcom.com (Paul Haahr)]

Jeffrey C. Rogers writes:
>  - Is there any way to make open descriptors hang around and remain open 
> between commands, or permanently (until otherwise affected) with exec?

This is minorly different from rc and other shells, due to some ultra
important reason having to do with es semantics that I've forgotten.
The redirections following exec must be enclosed in braces, so:

	; echo tofu > food
	; exec { <[4] food }
	; cat <[0=4]
	tofu
	; exec { <[4=] }
	; cat <[0=4]
	dup: Bad file number
	; 

>  - 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)

Yeah, that probably counts as a bug.  Should probably signal an error.
Hadn't this been hashed out before?  Was there a reason?  I'll check the
list archives one of these days.

>  - 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? 

As I remember -- and it's been a while -- there's some form of parsing
context that includes the file descriptor that input is coming from, and
parse has to use that for reasons having to do with buffering and
look-ahead.  The internal function runfd() should probably be exposed so
you can do the sort of thing you're looking for.  When I was last
actively working on es (over a year ago), I know that I was thinking
about the read-eval-print loop and how to make it more flexible, based
on comments from the list, but I've forgotten a lot of 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?

I think of the assertions really as ``can't happen'' events, and if one
is happening, the sky is falling, as far as I'm concerned.  I tend to be
over-cautious at times, in that I assert things which I know to be true
because the calling function, for example, makes the same assertion, but
I consider it a useful way to prevent myself from introducing bugs.

Paul