Re: es %dup

[Donn Cave <donn@u.washington.edu>]

| my current feeling is that if a %dup is executed with a file descriptor
| that es is using (for example, the history file or the script es is running),
| es should move the file descriptor it's using around to clear it out for
| the user.  it seems to me that one never want to dup the history file
| and hand it as input to some program, especially since there is no way
| other than trial and error to get at it.

If I get you right, here you're talking about the original file descriptor,
e.g., in "%dup 1 2 {foo}" that would be "1".  The user presumes that the
original fd is open, and presumably has reason to suspect what's on it.
I.e., if I take a notion to say "foo <[3=0]", it will be because I have
previously arranged for a file to be open on 3, and if so es isn't going
to open the history file on 3 because that fd is already open.  I'm not
personally concerned about this one, although as you say it's not
particularly useful to deliver internal file descriptors, however unlikely
that anyone will ask for them.

| anyhow, i think we will be able to implement those semantics, so expect
| them in 0.7.  here's a question though, what should this do?
| 
|	echo ls > foo
|	echo 'exec {<foo}' | es
|
| here's what is does in a couple of cases
|
| ;; echo ls > foo
| ;; echo 'exec <foo' | rc
| CHANGES         es.h            glom.c          makefile        parse.y 
...

| now it seems to me like this is wrong:  that is, in these examples, stdin (fd 0)
| is owned by the shell and it shouldn't be touched by the user.
|
| comments, anyone?

Well, I certainly agree, inasmuch as this is what my patch fixes.  I wouldn't
put it exactly like that, though - the shell command input fd is owned by the
shell, but of course the user has to be able to work with unit 0.  So, after
the "exec <foo", an application invoked by es should find "ls" on its input
stream, but the next es command still should come from the original command
input stream.

That's actually what happens when es is reading commands from a file or pipe,
since the command stream gets buffered ahead of the execution of the dot-file.
It just doesn't work currently with ttys, or with pipes that act like ttys in
that the whole command stream doesn't arrive all at once, since es goes back
to read more stuff from istack->fd, and someone switched horses in midstream.

	Donn Cave, University Computing Services, University of Washington
	donn@cac.washington.edu